Il semplice numero dei record può far sembrare la capacità di migrazione più lineare di quanto sia realmente. Product, Customer, Order e Blog Posts non contribuiscono allo stesso modo al fabbisogno conteggiato, e uno store contiene molte strutture importanti che non consumano Entity Points in modo autonomo.
Gli Entity Points sono il sistema di capacità ponderata utilizzato nei servizi di migrazione Next-Cart. Risolvono un problema specifico di pianificazione: trasformare quattro tipi di dati conteggiati in un fabbisogno di capacità ponderato. Non misurano la complessità, non garantiscono la compatibilità, non limitano la migrazione alle quantità inserite durante l’acquisto e non dimostrano che lo store di destinazione sarà utilizzabile.
Questa distinzione è essenziale. Se gli Entity Points vengono trattati come misura complessiva del progetto, uno store con volumi elevati ma struttura prevedibile può sembrare inutilmente complesso, mentre uno store con pochi record ma relazioni personalizzate può apparire ingannevolmente semplice.
Distingui la capacità dalla difficoltà della migrazione
Gli Entity Points conteggiano:
- Product;
- Customer;
- Order;
- Blog Posts.
Altri dati supportati possono comunque rientrare nella migrazione, tra cui Taxes, Manufacturers, Categories, Reviews, Coupons e CMS Pages. Queste strutture possono essere decisive per il risultato anche se non consumano Entity Points separatamente.
La difficoltà della migrazione può inoltre dipendere da:
- relazioni tra opzioni e varianti Product;
- campi o tabelle personalizzati;
- dati di applicazioni, plugin, moduli o estensioni;
- identificatori esterni;
- limiti del modello dati della piattaforma di destinazione;
- requisiti relativi ad Add-ons o Custom Service;
- dipendenze di validazione e lancio.
Due store possono richiedere la stessa capacità in Entity Points e avere bisogno di approcci di migrazione diversi. La capacità descrive il volume conteggiato. La complessità descrive il lavoro necessario per preservare il significato dei dati e produrre un risultato accettabile.
Trasforma i record idonei in capacità ponderata
Ogni tipo di dati conteggiato negli Entity Points ha un peso fisso:
| Tipo di dati conteggiato | Peso |
|---|---|
| Product | 1,0 |
| Customer | 0,5 |
| Order | 0,8 |
| Blog Posts | 0,6 |
Il calcolo è:
Entity Points
= (Product x 1,0)
+ (Customer x 0,5)
+ (Order x 0,8)
+ (Blog Posts x 0,6)
Supponiamo che uno store di origine contenga le seguenti quantità stimate:
| Tipo di dati conteggiato | Record stimati | Peso | Entity Points stimati |
|---|---|---|---|
| Product | 200 | 1,0 | 200 |
| Customer | 200 | 0,5 | 100 |
| Order | 150 | 0,8 | 120 |
| Blog Posts | 100 | 0,6 | 60 |
| Totale | 480 |
Il fabbisogno stimato è di 480 Entity Points. Un piano da 500 punti potrebbe coprire questa stima con 20 punti di margine. Un piano da 1.000 punti lascerebbe 520 punti di margine.
Il calcolo è semplice. La parte che richiede valutazione consiste nel capire se le quantità sono realistiche e quanta attività aggiuntiva potrebbe generare lo store di origine prima che la migrazione sia completata.
Considera la stima all’acquisto come una previsione
Le quantità inserite durante l’acquisto servono a stimare gli Entity Points e a selezionare il piano. Non creano filtri automatici sui record.
Se vengono inseriti 200 Products ma l’ambito selezionato nella sorgente contiene 260 Products rilevati, la migrazione non riceve l’istruzione di fermarsi al record numero 200 solo perché quella era la stima. I record conteggiati e migrati con successo consumano la capacità disponibile in base ai valori effettivi.
Questo produce tre numeri diversi:
| Numero | Significato |
|---|---|
| Fabbisogno stimato | La previsione usata per scegliere il piano |
| Capacità del piano | La capacità conteggiata massima disponibile nel piano acquistato |
| Consumo effettivo | Gli Entity Points utilizzati dai record idonei migrati con successo |
Tenere separati questi valori evita due errori comuni. Il primo è presumere che la stima costituisca un limite rigido della migrazione. Il secondo è presumere che la capacità inutilizzata scompaia soltanto perché la stima iniziale era più bassa.
Se devono essere migrati soltanto determinati record, il requisito va definito tramite Data Filter con condizioni basate sui campi per ciascun tipo di dati rilevante, oppure va valutato come filtraggio personalizzato quando il comportamento disponibile non è sufficiente.
Prevedi variazioni e crescita dello store di origine
Le stime differiscono spesso dal consumo effettivo perché l’inventario della sorgente era incompleto, lo store ha continuato a ricevere attività oppure Blog Posts, Customers o Orders inizialmente trascurati sono entrati nell’ambito della migrazione.
Supponiamo che per la stima da 480 punti dell’esempio precedente sia stato scelto un piano da 1.000 punti. Se il consumo effettivo raggiunge 800 Entity Points, la migrazione rimane entro il piano e restano 200 punti disponibili.
| Posizione di capacità | Entity Points |
|---|---|
| Capacità del piano | 1.000 |
| Stima all’acquisto | 480 |
| Consumo effettivo | 800 |
| Capacità residua | 200 |
La stima iniziale non impedisce la migrazione degli ulteriori record idonei. Il limite pratico rimane la capacità del piano.
Un margine aggiuntivo è particolarmente utile quando:
- lo store di origine rimane attivo durante la preparazione;
- il numero di record deriva da report parziali;
- i dati storici erano stati inizialmente esclusi dalla stima;
- Blog Posts o Orders archiviati sono facili da trascurare;
- sono previste ulteriori attività di migrazione prima del lancio.
Il margine deve comunque essere intenzionale. Acquistare un piano molto più grande non risolve un ambito poco chiaro, dati personalizzati o una validazione debole.
Che cosa succede quando la capacità si esaurisce
Il consumo effettivo segue questa sequenza per i tipi di dati conteggiati:
Product -> Customer -> Order -> Blog Posts
Se gli Entity Points disponibili si esauriscono prima che tutti i record conteggiati siano stati migrati, l’elaborazione si mette in pausa nel punto in cui viene raggiunta la capacità. È quindi possibile selezionare un Entity Points Plan superiore per ottenere la capacità aggiuntiva necessaria.
Consideriamo uno store il cui fabbisogno conteggiato effettivo è di 1.175 Entity Points:
| Tipo di dati conteggiato | Record effettivi | Peso | Entity Points necessari |
|---|---|---|---|
| Product | 600 | 1,0 | 600 |
| Customer | 600 | 0,5 | 300 |
| Order | 250 | 0,8 | 200 |
| Blog Posts | 125 | 0,6 | 75 |
| Totale | 1.175 |
Con un piano da 1.000 punti, i Products utilizzano 600 punti e i Customers altri 300. Restano soltanto 100 punti per gli Orders, sufficienti per 125 Orders a 0,8 punti ciascuno. I restanti 125 Orders e i 125 Blog Posts richiedono capacità aggiuntiva.
| Passaggio di consumo | Punti usati | Totale progressivo | Risultato entro 1.000 punti |
|---|---|---|---|
| Product | 600 | 600 | 600 Products |
| Customer | 300 | 900 | 600 Customers |
| Order | 100 dei 200 necessari | 1.000 | 125 Orders |
| Blog Posts | 0 dei 75 necessari | 1.000 | Nessun Blog Post prima dell’esaurimento della capacità |
L’esempio mostra perché la pianificazione della capacità richiede sia calcolo sia conoscenza della sorgente. Una sottostima anche modesta può influire su un tipo di dati successivo a causa della sequenza di consumo.
Non confondere la sequenza di capacità con la sequenza di migrazione
Il processo di migrazione gestisce i tipi di dati supportati in questo ordine:
Taxes -> Manufacturers -> Categories -> Products -> Customers -> Orders -> Reviews -> Coupons -> CMS Pages -> Blog Posts
Il consumo degli Entity Points si applica soltanto a Product, Customer, Order e Blog Posts. Le due sequenze descrivono aspetti diversi della stessa migrazione:
- la sequenza di migrazione descrive l’ordine con cui vengono elaborati i tipi di dati supportati;
- la sequenza degli Entity Points descrive come viene consumata la capacità conteggiata.
Questa distinzione spiega perché Categories o Reviews possano essere importanti per il risultato senza comparire come addebiti separati di Entity Points. La loro importanza è strutturale, non è definita dalla formula di capacità.
Applica gli Entity Points alle attività di migrazione successive
Gli Entity Points sono collegati ai record conteggiati e al fatto che tali record siano già stati conteggiati o meno all’interno della migrazione acquistata e del suo percorso fisso.
| Situazione del record | Effetto sulla capacità |
|---|---|
| Un record idoneo viene migrato con successo per la prima volta | Consuma Entity Points in base al proprio peso fisso |
| Un record idoneo è già stato conteggiato nella migrazione acquistata e nel percorso fisso | Lo stesso record non consuma nuovamente Entity Points solo perché un’altra azione di migrazione lo elabora |
| Un nuovo record idoneo viene aggiunto e migrato in seguito | Consuma Entity Points quando viene migrato con successo per la prima volta |
| Una nuova azione di migrazione include record idonei già conteggiati nella migrazione acquistata e nel percorso fisso | I record già conteggiati non consumano nuovamente Entity Points |
L’azione di migrazione non determina da sola il consumo. Continue the Migration with the Last Used Configuration, Continue the Migration with a New Configuration e Perform a New Migration possono tutte elaborare una combinazione di record esistenti e nuovi. Il consumo dipende dal fatto che ciascun record idoneo sia già stato conteggiato o meno nella migrazione acquistata e nel percorso fisso.
Questa regola rende utile la capacità residua per le attività successive sulla sorgente. Significa anche che il progetto dovrebbe tenere traccia di nuovi Products, Customers, Orders e Blog Posts quando lo store di origine rimane attivo.
Usa gli Entity Points per la decisione corretta
Gli Entity Points devono guidare:
- scelta del piano;
- pianificazione del margine;
- monitoraggio del consumo effettivo;
- upgrade del piano;
- crescita successiva dei record idonei.
Non devono decidere:
- Standard, Managed o Custom Service;
- se è necessario un Add-on;
- se una struttura dati personalizzata è supportata;
- se l’implementazione della piattaforma di destinazione è inclusa;
- se il risultato della migrazione è accettabile.
Queste decisioni richiedono riscontri sull’ambito, analisi delle responsabilità e validazione. Un totale preciso di Entity Points è necessario per il prezzo, ma non sostituisce la comprensione dei dati.
Questa distinzione evita due errori opposti di pianificazione. Uno store può richiedere un Entity Points Plan più grande e rimanere semplice da migrare, oppure può rientrare in un piano più piccolo ma avere relazioni personalizzate che richiedono un’analisi più approfondita. Capacità e complessità devono quindi essere valutate insieme, senza mai trattarle come la stessa misura.
Conclusione
Nei servizi di migrazione Next-Cart, gli Entity Points trasformano le quantità di Product, Customer, Order e Blog Posts in capacità di migrazione ponderata. La stima all’acquisto aiuta a scegliere un piano, la capacità del piano definisce il limite disponibile e il consumo è determinato dai record idonei effettivamente migrati con successo.
La disciplina centrale consiste nel mantenere separate le diverse dimensioni. La capacità non è complessità. Le quantità stimate non sono filtri. La sequenza di migrazione non è la sequenza degli Entity Points. Un’azione successiva non consuma automaticamente altri punti per record già conteggiati nella migrazione acquistata e nel percorso fisso.
Con queste distinzioni, gli Entity Points diventano uno strumento utile di pianificazione anziché un punteggio fuorviante per l’intero progetto di migrazione.
Domande frequenti
Quali record vengono conteggiati negli Entity Points?
Product, Customer, Order e Blog Posts sono i quattro tipi di dati conteggiati.
Come vengono calcolati gli Entity Points?
Product ha un peso fisso di 1,0, Customer di 0,5, Order di 0,8 e Blog Posts di 0,6.
Le quantità inserite durante l’acquisto limitano i record che vengono migrati?
No. Servono alla stima e alla scelta del piano. Non agiscono come filtri sui record.
Che cosa succede se il consumo effettivo supera la stima?
La migrazione può continuare finché rimane capacità sufficiente nel piano. Se la capacità si esaurisce, l’elaborazione si mette in pausa finché non viene resa disponibile capacità aggiuntiva.
Gli Entity Points inutilizzati possono supportare attività di migrazione successive?
Sì. La capacità residua può essere utilizzata per record idonei migrati successivamente all’interno della migrazione acquistata e del percorso fisso.
I record consumano nuovamente Entity Points durante un’azione successiva?
Non quando gli stessi record conteggiati sono già stati registrati all’interno della migrazione acquistata e del percorso fisso. I nuovi record idonei consumano punti quando vengono migrati con successo per la prima volta.
Categories, Reviews o CMS Pages consumano Entity Points?
Non consumano Entity Points in modo autonomo. Possono comunque essere parti importanti dell’ambito di migrazione supportato e della validazione.