PaaS uniquement

Bonnes pratiques pour modifier les tables de base de données

Dernière mise à jour : 5 mai 2025

Créé pour :

  • Expérimenté
  • Développeur

Cet article présente les bonnes pratiques de modification des tables de base de données créées par Adobe Commerce ou des modules tiers. Comprendre quand et comment modifier efficacement les tables permet d’assurer la viabilité et la stabilité à long terme de votre plateforme commerciale.

La migration depuis Magento 1 et d’autres plateformes de commerce électronique, ou l’utilisation de modules à partir de Adobe Commerce Marketplace, peut nécessiter l’ajout et l’enregistrement de données supplémentaires. Votre premier instinct peut être d'ajouter une colonne à une table de base de données ou d'en ajuster une existante. Cependant, vous ne devez modifier qu’une table Adobe Commerce principale (ou une table de fournisseurs tiers) dans des situations limitées.

Pourquoi Adobe recommande d’éviter les modifications

La principale raison pour laquelle vous ne pouvez pas modifier les tables principales est qu’Adobe Commerce inclut une logique sous-jacente contenant des requêtes SQL brutes. Les modifications apportées à la structure du tableau peuvent entraîner des effets secondaires inattendus, difficiles à résoudre. La modification peut également affecter les opérations DDL (Data Definition Language), ce qui a un impact inattendu et imprévisible sur les performances.

Une autre raison d’éviter de modifier la structure de la table de base de données est que vos modifications peuvent entraîner des problèmes si l’équipe de développement principale ou les développeurs tiers modifient la structure de leurs tables de base de données. Par exemple, il existe quelques tables de base de données principales qui ont une colonne appelée additional_data. Il a toujours été de type colonne text. Cependant, pour des raisons de performances, l’équipe principale peut remplacer la colonne par longtext. Ce type de colonne est un alias pour JSON. En effectuant une conversion vers ce type de colonne, les performances et la recherche sont ajoutées à cette colonne, qui n’existe pas comme type text. Vous pouvez en savoir plus sur cette rubrique dans JSON data type.

Savoir quand enregistrer ou supprimer des données

Adobe recommande de déterminer d’abord si vous devez enregistrer ces données. Si vous déplacez des données d’un système hérité, toutes les données que vous pouvez supprimer vous font gagner du temps et vous font gagner du temps lors de la migration. (Il existe des moyens d’archiver des données si elles doivent être consultées ultérieurement.) Pour être un bon gestionnaire de l’application et des performances, il est acceptable de contester une demande d’enregistrement de données supplémentaires. Votre objectif est de vous assurer que l’enregistrement des données est nécessaire pour répondre à un besoin de l’entreprise qui ne peut pas être rempli d’une autre manière.

Données héritées

Si votre projet contient des données héritées, telles que d’anciennes commandes ou des enregistrements de clients, envisagez une autre méthode de recherche. Par exemple, si l’entreprise n’a besoin de l’accès aux données que pour des références occasionnelles, envisagez d’implémenter une recherche externe de l’ancienne base de données hébergée en dehors de la plateforme commerciale au lieu de migrer les anciennes données vers Adobe Commerce.

Dans ce cas, la base de données doit être migrée vers un serveur, offrant soit une interface web pour lire les données, soit une formation à l’utilisation de MySQL Workbench ou d’outils similaires. L’exclusion de ces données de la nouvelle base de données accélère la migration en permettant à l’équipe de développement de se concentrer sur le nouveau site plutôt que de résoudre les problèmes de migration des données.

Une autre option connexe permettant de conserver les données à l’extérieur du commerce, mais vous permettant de les utiliser en temps réel, consiste à utiliser d’autres outils, tels que GraphQL mesh. Cette option combine différentes sources de données et les renvoie sous la forme d’une seule réponse.

Par exemple, vous pouvez stitch rassembler d’anciennes commandes provenant d’une base de données externe, par exemple l’ancien site Magento 1 qui est mis hors service. Ensuite, à l’aide de l’impression GraphQL, affichez-les dans l’historique des commandes des clients. Ces anciennes commandes peuvent être combinées avec les commandes de votre environnement Adobe Commerce actuel.

Pour plus d’informations sur l’utilisation de l’impression d’API avec GraphQL, voir What is API Mesh) et GraphQL Mesh Gateway.

Migration des données héritées avec des attributs d’extension

Si vous déterminez que les données héritées nécessitent une migration ou que de nouvelles données doivent être enregistrées dans Adobe Commerce, Adobe recommande d’utiliser les attributs d’extension. L’utilisation d’attributs d’extension pour enregistrer des données supplémentaires présente les avantages suivants :

  • Vous pouvez contrôler les données conservées et la structure de la base de données, ce qui garantit que les données sont enregistrées avec le type de colonne correct et les index adéquats.
  • La plupart des entités de Adobe Commerce prennent en charge l’utilisation des attributs d’extension.
  • Les attributs d’extension sont un mécanisme indépendant du stockage qui offre la possibilité d’enregistrer les données à l’emplacement optimal de votre projet.

Deux exemples d’emplacements de stockage sont les tables de base de données et Redis. Les éléments essentiels à prendre en compte lors du choix d’un emplacement sont les suivants : l’emplacement introduit une complexité supplémentaire ou affecte les performances.

Considérer d'autres alternatives

En tant que développeur, il est essentiel de toujours envisager d’utiliser des outils en dehors de votre environnement Adobe Commerce, tels que GraphQL mesh et Adobe App Builder. Ces outils peuvent vous aider à conserver l’accès aux données, mais n’ont aucun impact sur l’application commerciale principale ou ses tables de base de données sous-jacentes. Grâce à cette approche, vous exposez vos données par le biais d’une API. Vous ajoutez ensuite une source de données à votre configuration App Builder. Avec GraphQL Mesh, vous pouvez combiner ces sources de données et produire une seule réponse comme mentionné dans données héritées.

Pour plus d’informations sur l’impression GraphQL, voir GraphQL Mesh Gateway. Pour plus d’informations sur l’Adobe App Builder, voir Présentation d’App Builder.

Modification d’un tableau principal ou d’un tableau tiers

Si vous décidez de stocker des données en modifiant un tableau de base de données de module principal Adobe Commerce ou tiers, suivez les instructions ci-après pour minimiser l’impact sur la stabilité et les performances.

  • Ajouter de nouvelles colonnes uniquement.
  • Ne modifiez jamais la valeur type d’une colonne existante. Par exemple, ne remplacez pas un integer par varchar pour répondre à votre cas d’utilisation unique.
  • Évitez d’ajouter des colonnes aux tables d’attributs de la VEC. Ces tables sont déjà surchargées de logique et de responsabilité.
  • Avant d’ajuster un tableau, déterminez sa taille. La modification de tables volumineuses a un impact sur le déploiement, ce qui peut entraîner des minutes ou des heures de retard lorsque des modifications sont appliquées.

Bonnes pratiques pour modifier une table de base externe

Adobe recommande de procéder comme suit lorsque vous ajoutez une colonne à un tableau de base de données principal ou à un tableau tiers :

  1. Créez un module avec un nom dans votre espace de noms qui représente ce que vous mettez à jour.

    Par exemple : app/code/YourCompany/Customer

  2. Créez les fichiers appropriés pour activer le module (voir Création d’un module.

  3. Créez un fichier appelé db_schema.xml dans le dossier etc et apportez les modifications appropriées.

    Le cas échéant, générez un fichier db_schema_whitelist.json. Pour plus d’informations, voir Schéma déclaratif .