Nous sommes au milieu de refactoring un middleware / API sur mesure de Python 2 à 3. Le logiciel est responsable de la création et de la mise à jour des catégories, des produits, des listes, des commandes, des stocks, etc. sur de nombreuses plateformes différentes (comme eBay , Amazon, Shopware) par des données exportées depuis notre logiciel ERP. Le logiciel s'exécute sur un serveur Ubuntu virtualisé et possède sa propre base de données Mariahb, où elle fonctionne tous les jours. Nous atteignons les scripts responsables de la transformation des exportations de données Softwares ERP et nous débatons maintenant sur la «meilleure» approche sur la manière de gérer certaines tables associatives de la nôtre.
Un exemple: Il existe deux tables pour traiter des relations de produits à image, «Global_images» (~ 140k lignes) et «Article_Image_mapping» (~ 250K lignes). 'Global_images' contient le nom de fichier d'images ainsi que l'ordre de tri et est référencé via son identifiant dans "Article_Image_mapping" avec l'ID de produit de correction. Chaque fois qu'un produit reçoit une nouvelle image par exemple, nous devons veiller à conserver toutes les entrées à jour. L'ancienne ligne "Article_Image_Mapping" doit être supprimée, la nouvelle personne doit être référencée et nous devons également mettre à jour l'ordre de tri de toutes les entrées relatives à l'ID de produit.
Cette procédure bien sûr n'est pas grave, semblable à Mise à jour d'une table associative dans MySQL , mais nous pensions: Qu'est-ce qui nous empêche de tronquer simplement des tables et de les recréer tous les jours? Cela garderait notre code nettoyant et plus simple et aussi longtemps que l'ID de produit reste identique, d'autres références peuvent changer, mais elles aiment. En outre, nous ne violerons pas l'indice IA-Index avec des centaines de milliers de questions de mise à jour de clé en double, même si cela est probablement négligeable.
En quelque sorte cela ne se sent pas aussi élégant. Nous devons également nous assurer que notre manipulation d'exception est à la hausse, car d'autres scripts ne peuvent pas fonctionner sans la cartographie de l'image-produit.
3 Réponses :
"Meilleure pratique" est très une question basée sur une opinion - mais je peux décrire certaines des compromis.
Pour la maintenabilité, vous voulez probablement que la conception technique reflète le cycle de vie des entités commerciales aussi étroites que possible. De ce point de vue, "tronquer les tables et repeupler à partir de zéro" n'est probablement pas ce qu'un nouveau développeur s'attendrait - dans le domaine commercial, les photos ne disparaissent pas tous les soirs et réapparaissent le lendemain matin.
Pour des raisons de performances, repeuplez que tous les enregistrements 250K ne sont probablement pas géniaux - surtout si l'ensemble de données augmente au fil du temps.
Pour la résistance des bugs, rafraîchir les données Chaque nuit peut éviter les bogues, car les images du disque dur sont efficacement une relation de clé étrangère avec une entité située à l'extérieur de la base de données, et donc pas facilement vérifié à l'aide de la logique relationnelle standard.
D'autre part, cette résistance de bugs peut être problématique si vous devez écrire du code dédié à déterminer si la logique de la population d'images s'est terminée avant d'exécuter d'autres parties du script.
Si votre accent est mis sur les données étant corrigés, la reconstruction des tables entières chaque jour est une solution très raisonnable. Je ne sais pas quel est votre processus exact, mais s'il correspondait facilement à vos contraintes de temps pour la reconstruction et vos ressources, vous savez que les données sont ce que vous voulez.
L'avantage principal est que les données sont simples. Avec une approche update , vous devez faire face à L'inconvénient principal est que vous pourriez finir par réécrire l'historique. Si des modifications sont effectuées dans les données source qui affectent l'historique, les choses pourraient être déroutantes. Cela peut être un problème avec les rapports.
Je concevons souvent des systèmes reconstruits tous les jours. . . Mais il y a une mise en garde. Ils sont sur des serveurs de cloud où le stockage est essentiellement gratuit et nous pouvons archiver les anciennes copies pour voir «ce qui s'est vraiment passé» dans le passé. insert / update / Supprimer logique. Et lors de la manipulation des cas de bord, il pourrait ne pas être clair exactement ce que vous devez faire.
Si ce que vous chargez est un copie em> de tous les informations em> les informations, y compris les relations, alors faites ceci: charger toutes les nouvelles données dans nouvelles tables em>. p>
li>
fais cela dans une seule déclaration (pratiquement aucun temps d'arrêt): p>
Drop Table T1_OLD, T2_OOLD, ...; P>
li>
ol> pas de bruit, pas de muss, pratiquement aucun temps d'arrêt. p> (Si votre décharge quotidienne est incrémentielle, nous avons besoin de plus de détails.) p>
RENAME TABLE t1 TO t1_old, t1_new TO t1,
t2 TO t2_old, t2_new TO t2,
(etc);
étranger Clés code> peut trébucher n'importe quel schéma; Avez-vous de tels? Si tel est le cas, vous devez probablement les désactiver dans n'importe quelle action. P> P>
Qu'est-ce qui contrôle le "ordre de tri"? Quand un "produit reçoit une nouvelle image", n'est-ce pas simplement l'ajout d'une ligne à un nombre: beaucoup de table? Par "table associative", voulez-vous dire "nombre à plusieurs"? "Recréer chaque jour" - Avez-vous une nouvelle copie complète ou avez-vous besoin de reconstruire la ligne par ligne?