通用查找表替換

Question

大約五年前，我開始爲我正在開發的應用程序使用通用查找表。我知道，我可以聽到嘆息和你的拳頭在你的辦公桌上衝擊，但它已被證明會大大縮短開發時間。如果你想有一個回顧，並針對查找表的強音，傑克基督教做得很好，在這裏總結吧： http://www.projectdmx.com/dbdesign/lookup.aspx

的最後一個項目我發起了一個前幾天有近20種查找值，範圍從國家名稱改爲活動狀態。如果我們使用「合適的」關係模型，使用經典的N-Tier模型，並限制對存儲過程的數據訪問，我們將編寫20個表格，80個存儲過程（1個選擇，1個編輯，1個更新和1個刪除）。相反，Common Lookup Table有1個表格和4個SPs。由於對查找值的訪問更頻繁，因此我們將這些值緩存在ASP.NET應用程序對象中。

我的問題是什麼是替代品，除了創建一個表和每個查找類型4個SP？我只是開始將LINQ看作是我們的DAL（EntLib DAAB）的替代品，所以我也很樂意聽到關於LINQ的替代方案。

謝謝你的建議。

Answer 1

寫入表/存儲過程並不難，許多工具可以使這個相當平凡（甚至包括在MUCK樣式表中不可行的外鍵關係）。

什麼是硬處理更改這些結構。

雖然在您的開發階段，您可能會意識到模型的某些方面是不正確的，並且需要簡單（它不是浮點數）或複雜（我們需要在這兩個表格之間增加一層）更改。如果你只有一個開發數據庫，​​這對多個開發者來說可能是痛苦的，但不是世界末日。

但是在生產中的變化可能非常複雜並且很難處理（有時需要一次更新所有應用程序）。 CRUD存儲過程避免了幾乎所有這些簡單變化的問題，但對於複雜的變更並沒有什麼幫助（實際上它們甚至可能阻礙它），但從根本上來說，結構已經發生了一些重大變化，並且很可能如果你是使用一個你會以某種方式錯過這個MUCK，並開始把無效的數據放入你的數據庫。

使用LINQ to SQL不幫助很大這裏，因爲它只是讓你寫的代碼看起來類似於SQL [1]（存儲過程實際上的方式獲得IMO），但它將讓你知道在編譯時，您的數據庫代碼對於數據庫模式中某些重大更改（特別是關於FK關係）的某些類型不再有效。對於「語義」更改（如更改主鍵以覆蓋更多/更少的列）沒有多大用處。

在開始開發時，您可以通過爲每個開發人員提供自己的數據庫（最好是本地數據庫）來減少數據庫更改的開銷。當然，這很大程度上取決於相關的成本。

MUCK表可以有其用途，尤其是當您希望能夠在無需花費的情況下即時創建/刪除新的「列」並保持其生命週期值時（模式更新會在許多生命週期中發揮作用技術），但這種用途相對較少。

通過每種類型都有一個表，你可以使Mucks在某些方面略微更令人愉快（在其他方面更糟糕），然後在插入/查找時獲得類型有效性（可以添加約束來檢查'category'被插入如果需要，是正確的類型）。其中一些可以隱藏在存儲過程之後。

[1]我喜歡這個不要誤會我的錯，它只是不幫助你的具體問題多