Ik begrijp je probleem, maar heb vragen over delen ervan, dus ik zal wat algemener zijn.
- Als het enigszins mogelijk is, zou ik magazijn-/reservemagazijngegevens opslaan met uw voorraadgegevens (ofwel direct aan magazijnen hangend, of als het productspecifiek is buiten de voorraadtabellen).
- Als de instellingen via uw bedrijfslogica moeten worden berekend, moeten de records aan de tabel order/order_item hangen
Wat betreft het implementeren van de structuur in SQL, ga ik ervan uit dat alle bestellingen vanuit één magazijn worden verzonden en dat de verzending aan de besteltafel moet worden gehangen (maar de ideeën moeten elders van toepassing zijn):
-
De oudere manier om nul/één back-upmagazijnen af te dwingen, zou zijn om een Warehouse_Source-record van de tabel Orders op te hangen en een veld "IsPrimary" of "ShippingPriority" op te nemen en vervolgens een samengestelde unieke index op te nemen die OrderID en IsPrimary/ShippingPriority bevat.
-
als u maar één back-upmagazijn heeft, kunt u de velden ShippingSource_WareHouseID en ShippingSource_Backup_WareHouseID aan de bestelling toevoegen. Hoewel, dit is niet de route die ik zou gaan.
In SQL 2008 en hoger hebben we de prachtige toevoeging Gefilterde indexen . Hiermee kunt u een WHERE-clausule aan uw index toevoegen - wat resulteert in een compactere index. Het heeft ook het extra voordeel dat je sommige dingen kunt bereiken die in het verleden alleen konden worden gedaan door middel van triggers.
- Je zou een unieke gefilterde index kunnen plaatsen op OrderID &IsPrimary/ShippingPriority (WHERE IsPrimary =0).
Voeg een opmerking of iets dergelijks toe als je wilt dat ik het verder uitleg.