我必须为我正在维护的Web应用程序添加一些功能，我必须决定修改数据库（Sql Server 2010）的路径，以便存储和检索应用程序所需的新数据。 / p>
“丑陋而快速” 路径
Web应用程序已经具有此“通用域表”，该表存储可通过存储过程检索和过滤的不同域数据，指定域字段。
类似的东西：
| Id | Description | Domain |
|------------|-------------|--------------|
| 001 | Apple | Fruit |
| 002 | Peach | Fruit |
| 003 | Banana | Fruit |
| A01 | Yellow | Color |
| A02 | Red | Color |
| A03 | Green | Color |
SP_GetDomainValues @Domain='Fruit'
该表已经有了应用层，可以毫不费力地存储和检索数据 我只需要创建一个数据库脚本，用我需要的新记录和适当的新域填充表 我应该补充一点，这个应用程序还有几个域表，每个域只存储一个域。
“好但很慢” 路径
我必须创建不同的表，存储过程和DAL方法来存储和检索数据。
我个人喜欢这两个main reasons的第二种方法：
在您自然加入时，使用查询中的数据要容易得多 表，而不是一个大表的子集
可以非常自然地使用外键约束验证数据， 如果你有一个表，也许是名字，这是不可行的 “genericDomain”。它不是完全可能的，它只是 凌乱使用约束
我倾向于认为，如果你没有某种刚性比率可以帮助决定选择哪种方式，你最终会每次都采取快速而肮脏的路径。
根据您的经验，这是一个糟糕的设计的第一选择，或者有些情况下可以使用而不会感到内疚？
答案 0 :(得分：4)
我会选择已经存在的东西：通过添加数据来完成工作对我来说听起来不错，即使它不是“完美”。
还要考虑您的“好”设计需要架构更改，新代码和测试，所有这些都是昂贵且带来风险。
答案 1 :(得分：1)
像往常一样，这取决于。
如果应用程序正在运行，并且没有可能的功能增强，那么可以只做快速而肮脏的事情，继续你的生活。该业务可能会感谢您，因为它是最快且最容易预测的路线。如果让代码处于比你发现的状态更好的状态，你会感到很难过，但是你希望能够继续开展更有价值的工作。
如果应用程序中存在错误，或者您将来可能需要添加更多功能，或者如果您是此类的长期维护所有者，则需要权衡未来的痛苦使用这种模式来对抗使其进入更易维持状态的短期痛苦。
正如@a_horse_with_no_name所写，你勾勒出的设计是众所周知的反模式。它是脆弱的 - 数据的变化可以以各种令人兴奋的方式打破应用程序;它依赖于许多不同的层，都了解底层数据存储机制，并能够记住“水果”的正确单词（包括套管和拼写以及任何流氓空间）。它依赖于应用程序逻辑来检查数据的有效性 - 没有引用完整性 - 并且在大多数情况下，这会在某个地方失败，因此无辜的最终用户输入他们认为正确的值，但是它以某种方式违反规则并且永远是丢失。
所以，如果你需要使用这段代码一段时间，我会考虑重构它。我首先为现有代码编写单元测试和集成测试，并尝试逐步重构应用程序的一部分以使用更合理的数据库模型。转换整个应用程序可能需要花费与原始构建相同的时间，并且大多数商业人士不会乐于听到添加几个简单的额外功能将需要整个重建 - 所以寻找务实的方式来到你的位置想去！