Migrer des données vers Zen Cart revient à les traduire dans un modèle commerce auto-hébergé où l’identité Product, le placement en Category, les noms d’options, les valeurs d’options, les attributs affectés, les couches de prix, les modules de totaux d’Order, les emplacements de contenu, les plugins et la configuration influencent tous le sens des enregistrements. Un Product ou un Order source peut paraître complet dans la base de données tout en ayant perdu les relations qui le rendent commercialisable ou compréhensible.
La distinction fondamentale se situe entre les enregistrements migrés et les structures qui permettent de les interpréter. Un choix Product peut nécessiter un nom d’option, une valeur d’option, une affectation au Product, un ajustement de prix ou de poids, un indicateur de sélection obligatoire et une représentation sur la ligne d’Order. Un Product présent dans plusieurs collections source peut nécessiter un seul Product Zen Cart lié à plusieurs Categories plutôt que plusieurs Products dupliqués. Une CMS Page peut devoir devenir une EZ-Page, une define page, une description de Category, une description de Product ou un autre emplacement de contenu.
Le sens des données Zen Cart est étroitement lié à la configuration
Zen Cart donne aux propriétaires de boutique un contrôle direct sur le catalogue, les prix, les modules, les modèles et les extensions de base de données. Ce contrôle crée un modèle de données riche en relations. Les Products sont reliés aux Categories, types de Product, attributs, images, fabricants, classes fiscales, Specials, remises sur quantité, téléchargements, métadonnées et configuration. Les Orders sont reliés aux attributs sélectionnés, adresses, totaux, Coupons, gift certificates, historique de statut, libellés de paiement et livraison, commentaires et références externes.
| Domaine de données source | Interprétation dans Zen Cart | Décision de relation cible |
|---|---|---|
| Product | Enregistrement vendable lié au placement en Category, au statut, modèle, prix, quantité, fiscalité, image, type et attributs | Déterminer quelles valeurs restent au niveau Product et lesquelles appartiennent aux attributs, prix, contenu ou plugins. |
| Placement en Category | Hiérarchie plus liens Product-to-Category | Préserver une seule identité Product tout en représentant tous les emplacements de navigation intentionnels. |
| Données d’options et d’attributs | Noms d’options, valeurs d’options, attributs Product affectés, indicateurs de sélection, effets sur prix/poids et téléchargements éventuels | Reconstruire toute la relation de choix plutôt que copier seulement les libellés. |
| Customer | Compte, adresses, état newsletter, contexte de groupe et relation aux Orders | Séparer l’identité actuelle du compte des instantanés de transactions historiques. |
| Order | Lignes Product, attributs sélectionnés, totaux, statut, adresses, commentaires et références | Préserver une preuve transactionnelle lisible sans laisser entendre que les modules actifs sont configurés. |
| Contenu | EZ-Pages, define pages, descriptions Product/Category, liens, bannières et métadonnées | Faire correspondre le contenu source à l’emplacement et au rôle de navigation Zen Cart qui le remplacent. |
| Données de plugin/personnalisées | Champs personnalisés, tables, modifications d’administration, modèles, intégrations et calculs modifiés | Préserver uniquement les enregistrements ayant un parent défini et un consommateur cible qui continue à les utiliser. |
Un bon modèle cible rend ces relations visibles avant le déplacement des données. Il ne traite pas la configuration, les modules, les modèles et les plugins comme des types d’enregistrement ordinaires, mais il n’ignore pas non plus les données dont ces composants sont propriétaires.
Les Products et leur placement lié en Category doivent conserver une seule identité
Un Product Zen Cart peut être associé à une ou plusieurs Categories. Le placement lié permet à la même identité Product d’apparaître dans plusieurs emplacements de Category sans créer de Products dupliqués. Cette distinction compte lorsque la plateforme source utilise des collections, départements, regroupements par marque, chemins de navigation ou ensembles de merchandising automatisés.
| Structure source | Question d’interprétation Zen Cart | Résultat relationnel |
|---|---|---|
| Famille hiérarchique permanente | Doit-elle devenir une arborescence de Category ? | Le placement Product reste compréhensible pour Customers et administrateurs. |
| Un Product dans plusieurs parcours de navigation | Un seul Product doit-il être lié à plusieurs Categories ? | Prix, stock, attributs et identité Product restent centralisés. |
| Collection par marque ou fournisseur | Doit-elle devenir une Category, une relation fabricant, une facette de recherche ou une page de contenu ? | La destination suit les besoins de navigation et d’administration plutôt que le nom de la structure source. |
| Collection saisonnière ou campagne | S’agit-il d’une hiérarchie durable ou d’un merchandising temporaire ? | Éviter de créer un encombrement permanent de Categories à partir de campagnes éphémères. |
| Parent source avec variantes enfants | Les enfants doivent-ils devenir des attributs, des Products indépendants ou une autre structure ? | L’identité Product, les prix, le stock et le sens des lignes d’Order restent intentionnels. |
| Product numérique | Quels type de Product, téléchargement, attribut et relation d’accès sont nécessaires ? | La livraison de fichier reste liée au Product acheté et à l’état de l’Order. |
Dupliquer un Product pour conserver plusieurs placements source peut fragmenter inventaire, prix, Reviews et administration. Lier le Product préserve l’identité centrale, mais seulement lorsque les regroupements source représentent réellement plusieurs emplacements de navigation et non des articles commerciaux distincts.
Le type de Product compte également. Un Product physique, document, Product musical, don ou article téléchargeable peut porter des champs et un fonctionnement de boutique différents. La cible ne doit pas forcer tous les articles source dans une représentation Product générique identique lorsque leur modèle de vente diffère.
Noms d’options, valeurs d’options et attributs forment un modèle de choix en trois parties
Les choix Product dans Zen Cart reposent sur trois structures liées : un nom d’option, une ou plusieurs valeurs d’options et des attributs qui affectent des paires nom d’option/valeur d’option à un Product. L’attribut affecté peut porter un comportement tel qu’un type d’affichage, une sélection par défaut ou obligatoire, un ajustement de prix, un ajustement de poids, un ordre de tri, une relation à un fichier téléchargeable et d’autres paramètres propres au Product.
| Couche relationnelle | Signification | Risque de traduction |
|---|---|---|
| Nom d’option | Dimension du choix, par exemple Couleur ou Taille | Créer des dimensions dupliquées ou incohérentes entre Products. |
| Valeur d’option | Valeur réutilisable telle que Rouge ou Grand | Fusionner des valeurs distinctes ou multiplier des valeurs équivalentes sans gouvernance. |
| Affectation d’attribut Product | Association propre au Product d’un nom d’option et d’une valeur | Perdre quels choix appartiennent à quel Product et quels effets commerciaux s’appliquent. |
| Indicateurs d’attribut | Comportement obligatoire/par défaut/affichage et autres règles de sélection | Autoriser des valeurs par défaut invalides ou supprimer des décisions obligatoires du Customer. |
| Effet sur prix ou poids | Ajustement commercial attaché à la valeur affectée | Conserver les libellés tout en modifiant les totaux panier ou le sens de la livraison. |
| Comportement texte/fichier/téléchargement | Saisie du Customer ou relation de livraison numérique | Aplatir une donnée interactive ou contrôlée par accès en simple texte descriptif. |
Une plateforme source peut stocker une variante comme un Product enfant avec son propre SKU et son propre inventaire. Les attributs Zen Cart peuvent représenter le choix de l’acheteur, mais le modèle cible doit décider comment préserver identifiants enfants, propriété du stock, images et sens du traitement logistique. Le libellé du choix seul ne suffit pas.
La source peut aussi utiliser des modificateurs qui dépendent les uns des autres. Ce comportement ne doit pas être supposé émerger d’affectations d’options ordinaires. La représentation cible a besoin d’une relation définie ou d’une extension capable d’interpréter cette dépendance.
Prix, Specials, remises, Coupons et totaux d’Order sont des couches distinctes
La tarification Zen Cart peut combiner prix de base du Product, ajustements de prix par attribut, Products tarifés par attributs, Specials, soldes, remises sur quantité, prix par groupe, Coupons, gift certificates, livraison, taxes, frais et modules de totaux d’Order. Ces couches interviennent à des étapes différentes du calcul dans la boutique et de l’interprétation des Orders historiques.
| Règle commerciale source | Question pour le modèle de données Zen Cart |
|---|---|
| Prix propre à une variante | Le montant appartient-il à un Product, à un ajustement d’attribut, à une structure tarifée par attribut ou à un Product indépendant ? |
| Prix promotionnel temporaire | Doit-il devenir un Special, une règle de soldes ou seulement une valeur historique ? |
| Remise sur volume | S’agit-il d’une remise sur quantité Product, d’un traitement par groupe, d’une règle de module ou d’une décision de prix externe ? |
| Prix par groupe Customer | Quelle relation Customer-to-group et quelle règle de prix le gouvernent ? |
| Coupon ou gift certificate | L’enregistrement est-il une règle active, un solde stocké, un historique d’utilisation ou un contexte d’Order historique ? |
| Ligne de frais, taxe, livraison ou crédit | Quelle relation de total d’Order explique le calcul du sous-total au total final ? |
Un Order historique peut contenir une ligne de Coupon ou gift certificate sans recréer la règle future ni le solde restant. Un Product peut posséder un ancien prix Special qui n’est plus pertinent dans la boutique cible. Le modèle cible doit préserver les preuves commerciales nécessaires aux Orders tout en définissant séparément les structures futures de prix et promotion.
Customers, adresses, groupes et identités externes nécessitent des propriétaires distincts
Les Customers Zen Cart peuvent porter l’identité du compte, les entrées du carnet d’adresses, l’état newsletter, l’historique des Orders, la tarification par groupe, des champs d’approbation ou de statut ainsi que des données de plugins ou systèmes externes. Les adresses de facturation et livraison enregistrées au moment de la transaction dans les Orders doivent rester distinctes du carnet d’adresses actuel du Customer.
| Donnée Customer | Question de relation cible |
|---|---|
| Identité du compte | Quels e-mail, nom, statut et résultat de gestion du mot de passe définissent le compte cible ? |
| Carnet d’adresses | Quelles adresses actuelles de facturation et livraison restent valides et correctement localisées ? |
| Adresse d’Order historique | Quel instantané d’adresse appartient à la transaction d’origine ? |
| Groupe Customer | Le groupe contrôle-t-il le prix, l’approbation, la communication ou un autre comportement configuré ? |
| Newsletter et consentement | Quelle préférence ou preuve actuelle fait autorité ? |
| Identifiant externe | Quel CRM, ERP, système fiscal, marketplace ou support reste propriétaire ? |
| Champ de plugin | Quel composant cible lira la valeur après migration ? |
Les noms de groupes ne doivent pas être traités comme une logique commerciale complète. Un Customer wholesale ou approuvé nécessite une relation définie avec le prix, l’accès ou le comportement d’approbation qui continuera dans la boutique cible. Si ce comportement appartient à un plugin ou à un système externe, l’enregistrement Customer doit conserver la clé nécessaire sans prétendre que le compte principal le recrée à lui seul.
Les Orders doivent conserver des attributs sélectionnés et des lignes calculées lisibles
Les Orders Zen Cart préservent l’historique transactionnel à travers les en-têtes d’Order, lignes Product, attributs sélectionnés, instantanés d’adresses, historique de statut, commentaires, taxes, livraison, remises, Coupons, gift certificates et lignes de totaux d’Order. Les attributs sélectionnés sont particulièrement importants parce que le nom du Product parent peut ne pas révéler la taille, la couleur, la personnalisation ou le téléchargement acheté par le Customer.
| Relation d’Order | Sens à préserver |
|---|---|
| Ligne Product | Nom acheté, modèle, quantité, prix, taxe et relation avec l’identité Product source. |
| Attributs sélectionnés | Paires exactes nom d’option/valeur d’option et toute saisie texte ou référence de fichier fournie par le Customer. |
| Totaux d’Order | Sous-total, remises, Coupons, gift certificates, frais, livraison, taxes et total final. |
| Statut et commentaires | Historique du processus et contexte du service Customer. |
| Libellés de paiement et livraison | Preuve de la transaction d’origine plutôt que modules actifs de la cible. |
| Références externes | Clés marketplace, comptabilité, ERP, passerelle, livraison ou support ayant encore de la valeur. |
L’Order doit rester compréhensible même si la taxonomie de statuts ou le fonctionnement des modules source n’a pas d’équivalent exact dans Zen Cart. Une mise en correspondance sémantique est préférable à la copie de libellés que les équipes pourraient mal interpréter.
Le texte historique du Product et des options doit également rester suffisamment stable pour expliquer la transaction même si le Product actif change ensuite. Un Order est la preuve de ce qui a été acheté à ce moment-là, pas simplement un pointeur vers l’enregistrement catalogue actuel.
Le contenu peut appartenir aux EZ-Pages, define pages, enregistrements catalogue ou modèles
Le contenu Zen Cart est réparti entre plusieurs emplacements. Les EZ-Pages peuvent fournir des liens internes ou externes et participer à la navigation d’en-tête, de pied de page ou de sidebox. Les define pages contiennent certains contenus précis de la boutique. Les descriptions Product et Category portent le contenu catalogue. Bannières, sideboxes, fichiers de langue, modèles et plugins peuvent apporter d’autres éléments de présentation ou navigation.
| Contenu source | Emplacement Zen Cart possible | Relation à préserver |
|---|---|---|
| Page de politique ou d’information | EZ-Page, define page ou autre structure de contenu | Identité de page, route, langue et placement dans la navigation. |
| Contenu de page d’entrée Category | Description de Category ou page de contenu séparée | Association à la Category et intention de navigation du Customer. |
| Guide d’achat Product | Description Product, EZ-Page ou contenu lié | Liens internes et relation avec les Products concernés. |
| Lien d’en-tête/pied de page | Placement EZ-Page, navigation de modèle ou configuration sidebox | La présence du contenu reste distincte de son emplacement de présentation. |
| Page de campagne | EZ-Page, page personnalisée ou route contrôlée par plugin | Le contenu durable est séparé du balisage propre au modèle source. |
| Métadonnées SEO | Champs Product, Category, EZ-Page ou contrôlés par plugin | Les métadonnées restent attachées au bon objet et à la bonne route. |
Migrer seulement le texte des pages ne préserve pas le modèle de navigation. Une page peut exister tout en disparaissant de l’en-tête, du pied de page, de la sidebox, du sitemap ou du réseau de liens internes. À l’inverse, un balisage de présentation copié depuis la source peut devenir inutilisable si le modèle cible ne sait pas l’interpréter.
Les plugins et enregistrements de base de données personnalisés nécessitent des relations de parent et de consommateur
Les boutiques Zen Cart anciennes ou fortement personnalisées contiennent souvent des plugins, fichiers du cœur modifiés, tables personnalisées, surcharges de modèles, surcharges de langue, extensions de rapports, générateurs de flux, modules SEO, intégrations de paiement et livraison et modifications des processus administratifs. Ces ajouts peuvent stocker des données métier durables, des données dérivées, de la configuration ou des résidus techniques.
| Modèle de donnée personnalisée | Décision pour le modèle cible |
|---|---|
| Champ personnalisé sur Product, Customer ou Order | Identifier son sens métier, son enregistrement parent, son champ cible et son propriétaire futur. |
| Entité appartenant à un plugin | Préserver l’entité et ses relations uniquement lorsqu’un plugin ou processus cible continuera à les consommer. |
| Table personnalisée | Distinguer les enregistrements faisant autorité des journaux, caches, index et données intermédiaires obsolètes. |
| Calcul modifié | Reconstruire la règle ou le module ; ne pas traiter la valeur calculée comme l’ensemble de la logique métier. |
| Surcharge de modèle ou de langue | Extraire le contenu durable tout en reconstruisant la présentation dans le système de modèles cible. |
| Clé de système externe | Préserver les identifiants inter-systèmes stables sur la bonne relation Product, Customer ou Order. |
Le schéma de base de données peut révéler où une valeur est stockée sans indiquer si elle fait toujours autorité. Une table de plugin peut contenir des données critiques d’abonnement, livraison, marketplace ou rapports. Elle peut également contenir des caches obsolètes qui ne doivent jamais être promus dans le modèle cible. La propriété et l’usage futur permettent de faire la différence.
La propriété des données doit être définie avant la mise en correspondance des champs
Un modèle cible Zen Cart cohérent classe chaque valeur source importante dans l’un des résultats suivants :
- relation native Product, Category, option, attribut, Customer, Order, Coupon, Review, contenu ou média ;
- donnée gouvernée personnalisée ou appartenant à un plugin avec un consommateur cible défini ;
- identité stable d’un système externe attachée au bon enregistrement parent ;
- configuration ou présentation cible qui doit être reconstruite plutôt que copiée comme donnée ;
- résidu obsolète, mis en cache, dérivé ou de faible valeur qui doit être archivé ou exclu.
| Domaine de décision | Question forte pour le modèle cible |
|---|---|
| Identité Product | L’article est-il un Product, un Product lié dans plusieurs Categories, un ensemble de choix d’attributs ou plusieurs Products indépendants ? |
| Choix Product | Quels nom d’option, valeur d’option, affectation Product, indicateurs et effets prix/poids forment le choix complet ? |
| Calculs commerciaux | Quelle valeur relève des données Product, de la tarification par attribut, d’une logique promotionnelle, d’un comportement de groupe Customer ou d’une preuve historique d’Order ? |
| Customers et Orders | Quelles identités actuelles, adresses, instantanés historiques, attributs sélectionnés et totaux doivent rester distincts ? |
| Contenu | Quel objet Zen Cart et quel emplacement de navigation donnent du sens au contenu ? |
| Plugins et intégrations | Quel composant cible ou système externe continue de posséder l’enregistrement ? |
Ce modèle fondé sur les relations évite deux extrêmes : copier toutes les tables source dans des champs personnalisés sans explication, ou supprimer des données hors cœur qui soutiennent encore les opérations. Zen Cart peut alors interpréter les enregistrements migrés comme une boutique cohérente plutôt que comme une archive de lignes issues du système source.
Conclusion
Les différences du modèle de données de Zen Cart se concentrent sur le placement Product-to-Category, les relations nom d’option/valeur d’option/attribut, les couches de prix, la propriété des Customers et adresses, les attributs et totaux d’Order, le placement des EZ-Pages et contenus, les plugins, tables personnalisées et identifiants externes.
Une migration fiable préserve toute la relation qui donne du sens à chaque valeur importante. Les Products gardent une identité unique dans leurs emplacements de navigation intentionnels, les choix Customer conservent leurs effets commerciaux, les Orders restent lisibles comme transactions historiques, le contenu reçoit un emplacement Zen Cart approprié et les enregistrements personnalisés ont un propriétaire futur.
Questions fréquentes
Pourquoi Zen Cart sépare-t-il noms d’options, valeurs d’options et attributs ?
Le nom d’option définit la dimension du choix, la valeur d’option définit une valeur possible et l’affectation d’attribut Product relie cette paire à un Product précis avec un comportement propre, par exemple prix, poids, ordre de tri, sélection obligatoire ou paramètres de téléchargement.
Un Product présent dans plusieurs collections source doit-il devenir plusieurs Products Zen Cart ?
En général non lorsque les enregistrements source représentent un seul Product commercial. Un Product Zen Cart peut être lié à plusieurs Categories afin de centraliser prix, stock, attributs et administration. Des Products séparés ne conviennent que lorsque les articles possèdent réellement des identités distinctes.
Chaque variante source peut-elle devenir un attribut Zen Cart ?
Pas automatiquement. Les variantes source peuvent posséder un SKU, un inventaire, des images, un coût, un code-barres ou une identité de traitement logistique qui dépasse la structure d’attribut prévue. Le modèle cible doit préserver ces relations ou utiliser des Products indépendants ou une structure prise en charge par une extension.
Comment représenter les totaux d’Order historiques ?
Conservez le sous-total, les remises, Coupons, gift certificates, frais, livraison, taxes et total final sous forme de lignes calculées compréhensibles rattachées à l’Order. Elles préservent la preuve transactionnelle sans recréer automatiquement les futures règles promotionnelles ou de modules.
Où les CMS Pages source doivent-elles être placées dans Zen Cart ?
Faites correspondre chaque page à son rôle cible : EZ-Page, define page, contenu Product ou Category, page personnalisée ou autre structure. Préservez séparément la route, la langue, les liens internes, les métadonnées et le placement prévu dans la navigation.
Comment classer les données de plugins et de tables personnalisées ?
Reliez chaque enregistrement à son objet parent, son objectif métier, son consommateur cible et son propriétaire futur. Préservez les entités faisant autorité et les clés d’intégration, reconstruisez les règles actives dans l’environnement cible et excluez les journaux, caches, index et résidus obsolètes sans valeur durable.