Je comprends votre problème, mais j'ai des questions sur certaines parties de celui-ci, donc je serai un peu plus général.
- Dans la mesure du possible, je stockerais les données d'entrepôt/d'entrepôt de sauvegarde avec vos données d'inventaire (soit directement suspendues aux entrepôts, soit si elles sont spécifiques au produit dans les tableaux d'inventaire).
- Si la configuration doit être calculée via votre logique métier, les enregistrements doivent être suspendus à la table order/order_item
En termes d'implémentation de la structure en SQL, je suppose que toutes les commandes sont expédiées à partir d'un seul entrepôt et que l'expédition doit être suspendue à la table des commandes (mais les idées devraient être applicables ailleurs) :
-
L'ancienne méthode pour appliquer zéro/un entrepôt de sauvegarde consisterait à suspendre un enregistrement Warehouse_Source de la table Orders et à inclure un champ "IsPrimary" ou "ShippingPriority", puis à inclure un index unique composite qui inclut OrderID et IsPrimary/ShippingPriority.
-
si vous n'aurez qu'un seul entrepôt de sauvegarde, vous pouvez ajouter les champs ShippingSource_WareHouseID et ShippingSource_Backup_WareHouseID à la commande. Bien que ce ne soit pas la voie que j'emprunterais.
Dans SQL 2008 et plus, nous avons le merveilleux ajout de Index filtrés . Ceux-ci vous permettent d'ajouter une clause WHERE à votre index, ce qui donne un index plus compact. Il a également l'avantage supplémentaire de vous permettre d'accomplir certaines choses qui ne pouvaient être faites que par des déclencheurs dans le passé.
- Vous pouvez mettre un index filtré Unique sur OrderID &IsPrimary/ShippingPriority (WHERE IsPrimary =0).
Ajoutez un commentaire ou autre si vous voulez que je vous explique davantage.
