Jag förstår ditt problem, men har frågor om delar av det, så jag ska vara lite mer allmän.
- Om det alls är möjligt skulle jag lagra lager-/backuplagerdata med dina lagerdata (antingen direkt hängande av lager eller om det är produktspecifikt utanför lagertabellerna).
- Om installationen måste beräknas genom din affärslogik bör posterna hänga från tabellen order/order_item
När det gäller hur man implementerar strukturen i SQL, antar jag att alla beställningar skickas från ett enda lager och att frakten måste hängas utanför beställningsbordet (men idéerna bör vara tillämpliga någon annanstans):
-
Det äldre sättet att upprätthålla noll/ett backup-lager skulle vara att hänga en Warehouse_Source-post i ordertabellen och inkludera ett "IsPrimary"-fält eller "ShippingPriority" och sedan inkludera ett sammansatt unikt index som inkluderar OrderID och IsPrimary/ShippingPriority.
-
om du bara någonsin kommer att ha ett reservlager kan du lägga till fälten ShippingSource_WareHouseID och ShippingSource_Backup_WareHouseID till beställningen. Fast det här är inte vägen jag skulle gå.
I SQL 2008 och senare har vi det underbara tillägget av Filtrerade index . Dessa låter dig lägga till en WHERE-sats till ditt index -- vilket resulterar i ett mer kompakt index. Det har också den extra fördelen att du kan åstadkomma vissa saker som bara kunde göras genom triggers i det förflutna.
- Du kan sätta ett unikt filtrerat index på OrderID &IsPrimary/ShippingPriority (WHERE IsPrimary =0).
Lägg till en kommentar eller liknande om du vill att jag ska förklara ytterligare.