Solo PaaS

Procedure consigliate per la modifica delle tabelle di database

Ultimo aggiornamento: 5 maggio 2025

Creato per:

  • Esperto
  • Sviluppatore

In questo articolo vengono fornite le procedure consigliate per la modifica delle tabelle di database create da Adobe Commerce o da moduli di terze parti. Scopri quando e come modificare efficacemente le tabelle per garantire la redditività a lungo termine e la stabilità della piattaforma commerce.

La migrazione da Magento 1 e altre piattaforme di e-commerce o l'utilizzo dei moduli del Marketplace Adobe Commerce può richiedere l'aggiunta e il salvataggio di dati aggiuntivi. Il primo istinto potrebbe essere quello di aggiungere una colonna a una tabella di database o di modificarne una esistente. Tuttavia, è consigliabile modificare una tabella Adobe Commerce di base (o una tabella fornitore di terze parti) solo in situazioni limitate.

Perché l’Adobe consiglia di evitare le modifiche

Il motivo principale per evitare di modificare le tabelle principali è che Adobe Commerce include una logica sottostante che contiene query SQL non elaborate. Le modifiche alla struttura della tabella possono causare effetti indesiderati imprevisti difficili da risolvere. La modifica può inoltre influire sulle operazioni DDL (Data Definition Language) causando impatti imprevisti e imprevedibili sulle prestazioni.

Un altro motivo per evitare di modificare la struttura della tabella di database è che le modifiche possono causare problemi se il team di sviluppo di base o sviluppatori di terze parti modificano la struttura delle tabelle di database. Alcune tabelle di database di base, ad esempio, contengono una colonna denominata additional_data. È sempre stato un tipo di colonna text. Tuttavia, per motivi di prestazioni, il team di base potrebbe cambiare la colonna in longtext. Questo tipo di colonna è un alias per JSON. La conversione in questo tipo di colonna comporta un aumento delle prestazioni e una maggiore ricercabilità, che non esiste come tipo text. Per ulteriori informazioni su questo argomento, consulta il tipo di dati JSON.

Sapere quando salvare o rimuovere i dati

L’Adobe consiglia di determinare innanzitutto se è necessario salvare questi dati. Se trasferisci dati da un sistema legacy, qualsiasi dato rimuovibile ti consente di risparmiare tempo e fatica durante la migrazione. Esistono diversi modi per archiviare i dati, se è necessario accedervi in un secondo momento. Per essere un buon amministratore dell’applicazione e delle prestazioni, è consentito contestare una richiesta di salvataggio di dati aggiuntivi. L’obiettivo è garantire che il salvataggio dei dati sia un requisito per soddisfare un’esigenza aziendale che non può essere soddisfatta in altro modo.

Dati legacy

Se il progetto contiene dati legacy, ad esempio vecchi ordini o record cliente, è consigliabile utilizzare un metodo di ricerca alternativo. Ad esempio, se l'azienda richiede l'accesso ai dati solo per un riferimento occasionale, è consigliabile implementare una ricerca esterna del vecchio database ospitato al di fuori della piattaforma commerce anziché eseguire la migrazione dei vecchi dati a Adobe Commerce.

Questa situazione richiederebbe la migrazione del database a un server, che offre un’interfaccia web per la lettura dei dati o forse una formazione sull’utilizzo di MySQL Workbench o strumenti simili. L’esclusione di questi dati dal nuovo database accelera la migrazione consentendo al team di sviluppo di concentrarsi sul nuovo sito anziché sulla risoluzione dei problemi di migrazione dei dati.

Un’altra opzione correlata per mantenere i dati esterni al commercio, ma consentendoti di utilizzarli in tempo reale, sarebbe quella di sfruttare altri strumenti, come GraphQL mesh. Questa opzione combina diverse origini di dati e le restituisce come una singola risposta.

È ad esempio possibile stitch raggruppare i vecchi ordini provenienti da un database esterno, ad esempio il vecchio sito del Magento 1 disattivato. Quindi, utilizzando GraphQL mesh, mostrale come parte della cronologia degli ordini dei clienti. Questi vecchi ordini possono essere combinati con quelli dell'ambiente Adobe Commerce corrente.

Per ulteriori informazioni sull'utilizzo di Mesh API con GraphQL, vedere Che cos'è Mesh API) e Gateway Mesh GraphQL.

Migrare i dati legacy con gli attributi dell’estensione

Se si stabilisce che i dati legacy devono essere migrati o che i nuovi dati devono essere salvati in Adobe Commerce, l'Adobe consiglia di utilizzare attributi di estensione. L’utilizzo degli attributi di estensione per salvare dati aggiuntivi offre i seguenti vantaggi:

  • Puoi controllare i dati persistenti e la struttura del database, in modo da garantire che vengano salvati con il tipo di colonna e gli indici corretti.
  • La maggior parte delle entità in Adobe Commerce supporta l'utilizzo degli attributi di estensione.
  • Gli attributi di estensione sono un meccanismo indipendente dall’archiviazione che offre la flessibilità di salvare i dati nella posizione ottimale per il progetto.

Due esempi di percorsi di archiviazione sono le tabelle di database e Redis. Quando si sceglie una posizione, è importante considerare se la posizione comporta una complessità aggiuntiva o influisce sulle prestazioni.

Valuta altre alternative

In qualità di sviluppatore, è fondamentale prendere sempre in considerazione l'utilizzo di strumenti al di fuori dell'ambiente Adobe Commerce, come GraphQL mesh e Adobe App Builder. Questi strumenti possono essere utili per mantenere l’accesso ai dati, ma non hanno alcun impatto sull’applicazione Commerce di base o sulle tabelle di database sottostanti. Con questo approccio, puoi esporre i dati tramite un’API. Quindi, aggiungi un’origine dati alla configurazione di App Builder. Utilizzando GraphQL Mesh, puoi combinare tali origini dati e produrre un'unica risposta come indicato in dati legacy.

Per ulteriori dettagli sulla rete GraphQL, vedere Gateway GraphQL Mesh. Per informazioni sull'Adobe App Builder, vedere Introduzione ad App Builder.

Modifica di una tabella core o di terze parti

Se si decide di archiviare i dati modificando una tabella di database di moduli di base Adobe Commerce o di terze parti, utilizzare le linee guida seguenti per ridurre al minimo l'impatto sulla stabilità e sulle prestazioni.

  • Aggiungi solo nuove colonne.
  • Non modificare mai il valore type di una colonna esistente. Ad esempio, non modificare integer in varchar per soddisfare il tuo caso d'uso univoco.
  • Evitare di aggiungere colonne alle tabelle degli attributi EAV. Queste tabelle sono già sovraccariche di logica e responsabilità.
  • Prima di regolare una tabella, determinarne le dimensioni. La modifica di tabelle di grandi dimensioni ha un impatto sulla distribuzione e può causare minuti o ore di ritardo nell’applicazione delle modifiche.

Procedure consigliate per la modifica di una tabella di database esterna

L'Adobe consiglia di eseguire la procedura seguente quando si aggiunge una colonna a una tabella di database di base o a una tabella di terze parti:

  1. Crea un modulo con un nome nello spazio dei nomi che rappresenti ciò che stai aggiornando.

    Esempio: app/code/YourCompany/Customer

  2. Creare i file appropriati per abilitare il modulo (vedere Creare un modulo.

  3. Creare un file denominato db_schema.xml nella cartella etc e apportare le modifiche appropriate.

    Se applicabile, generare un file db_schema_whitelist.json. Per ulteriori informazioni, vedere Schema dichiarativo.