大约五年前，我开始为我正在开发的应用程序使用通用查找表。我知道，我可以听到叹息和拳头撞击你的桌子，但事实证明它可以大大缩短开发时间。如果你想要一个回顾，以及强烈的反对查找表的声音，Jake Christian在这里做了很好的总结： http://www.projectdmx.com/dbdesign/lookup.aspx
我几天前发布的最后一个项目有大约20种类型的查找值，从状态名称到活动状态。使用经典的N层模型，并限制对存储过程的数据访问，如果我们使用“适当的”关系模型，我们将编写20个表，80个存储过程（1个选择，1个编辑，1个更新和1个删除）。相反，Common Lookup Table有1个表和4个SP。由于对查找值的访问更频繁，因此我们将值缓存在ASP.NET应用程序对象中。
除了为每个查找类型创建一个表和4个SP之外，我的问题是有哪些替代方案？我刚刚开始将LINQ视为我们的DAL（EntLib DAAB）的替代品，因此我也愿意听取LINQ替代方案。
先谢谢您的建议。
答案 0 :(得分：1)
编写表/存储过程并不难，有很多工具可以使这很简单（甚至包括在MUCK样式表中不可行的外键关系）。
处理这些结构的更改是多么困难。
虽然在您的开发阶段，您可能会意识到模型的某些方面是不正确的，并且需要简单（它的浮点数不是整数）或复杂（我们需要在这两个表之间有一个额外的层）更改。如果你只有一个开发数据库，这对于多个开发人员来说可能很痛苦，但不是世界末日。
生产中的变化可能非常复杂且难以处理（有时需要立即更新所有应用程序）。 CRUD存储过程对于简单的更改几乎避免了所有这些问题，但对于复杂的更改没有任何帮助（实际上它们甚至可能会阻碍它）但是从根本上说，结构已经以某种显着的方式发生了变化，如果你是使用MUCK，你会以某种方式错过这个，并开始将无效数据放入你的数据库。
使用Linq to Sql在这里没有多大帮助，因为它只是让你编写看起来类似于sql [1]的代码（存储过程实际上以IMO的方式进行）但它将在编译时让你知道你的db代码对于数据库模式中的某些类型的重大更改不再有效（特别是关于FK关系）。它不会用于“语义”更改，例如更改主键以覆盖更多/更少的列。
在最初开发的同时，通过为每个开发人员提供自己的数据库（最好是本地数据库），可以大大减少数据库更改的开销。这在很大程度上取决于当然涉及的相关费用。
MUCK表可以有它们的用途，特别是当你希望能够在没有成本的情况下动态创建/删除新的“列”并保持它们的生命周期价值时（架构更新使用许多生命周期技术来玩得很开心） ）但这种用途相对较少。
你可以通过在每个类型中使用一个表来使Mucks在某些方面稍微更愉快（但在其他方面更糟糕），然后在插入/查找时获得类型有效性（您可以添加检查插入的'类别'的约束条件如果需要，可以选择正确的类型）。其中一些可能隐藏在存储过程之后。
[1]我喜欢这不会让我错，它只是对你的具体问题没有多大帮助