幫助“靈活”與固定表
我們正在 SQL Server 中設計一個數據庫來處理銷售佣金。目前架構的圖表如下所示：
這個項目只有我們幾個人，我們的老闆把這個設計丟給了我們。我是新手，但我對這張
Slot桌子很擔心，因為看起來我們正朝著 EAV 模型前進，而且我認為我們的團隊沒有足夠的經驗來克服這些陷阱。A
Slot可以是公司、位置、地區、路線或位置（基於其SlotType）。我們有這些實體的表格，但管理層希望能夠“靈活”地相互分配插槽（SlotHierarchy）。我不會涉及適用於每個插槽、插槽類型、插槽級別、插槽級別類型和員工職位分配的生效日期的混亂。所有生效日期都是因為管理層希望控制每一件。計劃是將
Employeeget 分配給位置槽 (SlotPositionAssignment)，然後可以將其分配給位置、路線或區域槽。一個職位在給定時間只能分配一名員工。不過，一個位置可以分配給任意數量的插槽。因此，我們可能有
PositionType“銷售員”和SlotDesc“銷售員 1”和“銷售員 2”這兩個職位（職位），每個職位都分配有一名員工。這兩個位置可以分配給多個路線、區域、位置或公司位置。SlotHierarchy有助於解決這個問題。我擔心的是：
我擔心我們可能會因此而自取其辱。我不介意編寫額外的應用程序邏輯，但這似乎“太聰明了”。直言不諱並使用映射到現實生活的表格而不是將它們隱藏為“插槽”不是更有意義嗎？
我想取消將職位作為插槽並使用
Position表格，或者也許只是使用PositionType我們將失去報告公司特定職位的能力，例如“Rt 1 Manager”。當我提出這個問題時，我被告知它不會“靈活”，這就是它的結束。有沒有更好的方法來組織這個，或者做出一些妥協，或者我什麼都不擔心？我是新手，不介意犯錯，只要我知道為什麼我錯了。
我建議你考慮一下這個系統的案例。在您自己的腦海中計算查詢將如何尋找給定的設計和您的替代方案。包括人們在插槽之間移動的場景。更新是什麼樣的？可以在 DRI 中強制執行業務約束嗎？仍然可以找到所需的值嗎？有實際的例子來討論會突出你的擔憂，讓你的老闆更充分地解釋這個模型。
針對可怕的模式編寫恐怖查詢只是問題的一部分。當它們損壞時，必須有人在凌晨 3 點在沒有文件的情況下修復它們。在這個階段更易理解的查詢將更快地為您提供更好的系統。
如果它能讓你的神經平靜下來，我已經在 EAV 系統上取得了成功。也就是說，我們是一個由非常有經驗的 DBA 組成的團隊，這確實是一個藍天、“假設”項目，不，我們沒有把公司押在上面。任何將要投入生產的開發項目，我們都強烈反對使用 EAV 方法。
如果你走“靈活”路線，不要僅僅因為你有一個通用模式就嘗試編寫通用查詢。每個查詢只應處理公司、位置、地區或任何您的插槽類型之一。
我的兩分錢的價值。