Разбирам проблема ви, но имам въпроси относно части от него, така че ще бъда малко по-общ.
- Ако изобщо е възможно, бих съхранявал складови/резервни складови данни с вашите данни за инвентара (или директно окачване на складове, или ако е специфичен за продукт извън таблиците с инвентара).
- Ако настройката трябва да се изчисли чрез вашата бизнес логика, тогава записите трябва да висят извън таблицата order/order_item
По отношение на това как да внедря структурата в SQL, ще приема, че всички поръчки се доставят от един склад и че доставката трябва да бъде окачена извън таблицата с поръчки (но идеите трябва да са приложими и другаде):
-
По-старият начин за налагане на нула/един резервни складове би бил да се окачи Warehouse_Source запис на таблицата с поръчки и да се включи поле "IsPrimary" или "ShippingPriority", след което да се включи съставен уникален индекс, който включва OrderID и IsPrimary/ShippingPriority.
-
ако някога ще имате само един резервен склад, можете да добавите полета ShippingSource_WareHouseID и ShippingSource_Backup_WareHouseID към поръчката. Въпреки това, това не е маршрутът, по който бих тръгнал.
В SQL 2008 и по-нови имаме прекрасното допълнение на Филтрирани индекси . Те ви позволяват да добавите клауза WHERE към вашия индекс - което води до по-компактен индекс. Освен това има допълнителното предимство да ви позволява да постигнете някои неща, които в миналото можеха да бъдат направени само чрез тригери.
- Можете да поставите уникален филтриран индекс на OrderID &IsPrimary/ShippingPriority (WHERE IsPrimary =0).
Добавете коментар или нещо подобно, ако искате да обясня допълнително.
