6

我必须向我正在维护的 Web 应用程序添加一些功能，并且我必须决定遵循哪个路径来修改数据库 (Sql Server 2010) 以便存储和检索应用程序所需的新数据。

“丑陋但快速”的路径：
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 方法来存储和检索数据。

出于以下两个主要原因，我个人喜欢第二种方法：

  • 在查询中使用数据要容易得多，因为您可以自然地加入表，而不是一张大表的子集

  • 数据可以很自然地使用外键约束来验证，如果你有一个表，这可能是不可行的，可能命名为“genericDomain”。不是完全不可能，只是使用约束很麻烦

我倾向于认为，如果您没有某种可以帮助决定选择哪种方式的刚性比例，那么您最终每次都会走上快速而肮脏的道路。

根据您的经验，第一选择是一个糟糕的设计，还是在某些情况下可以使用它而不会感到太内疚？

4

2 回答 2

4

我只会使用已经存在的东西：通过添加数据来完成工作对我来说听起来不错，即使它不是“完美的”。

还要考虑到您的“好”设计需要模式更改、新代码和测试，所有这些都代价高昂并带有风险。

于 2012-11-06T11:58:15.127 回答
1

像往常一样，这取决于。

如果应用程序正在运行，并且没有可能的功能增强，您可以只做快速而肮脏的事情，然后继续您的生活。企业可能会感谢您，因为这是最快且最容易预测的路线。你会因为让代码处于没有比你发现它更好的状态而感到难过，但你希望接下来可以从事更有价值的工作。

如果应用程序中存在错误，或者您将来可能需要添加更多功能，或者如果您是这方面的长期维护所有者，您需要权衡未来使用此功能的痛苦模型以应对将其置于更可维护状态的短期痛苦。

正如@a_horse_with_no_name 所写，您概述的设计是众所周知的反模式。它很脆弱——数据的变化会以各种令人兴奋的方式破坏应用程序；它依赖于许多不同的层，它们都了解底层数据存储机制，并且能够记住“水果”的正确单词（包括大小写和拼写以及任何流氓空格）。它依赖于应用程序逻辑来检查数据的有效性 - 没有参照完整性 - 在大多数情况下，这会在某个地方失败，因此无辜的最终用户输入了他们认为正确的值，但它以某种方式违反了规则并且永远存在丢失。

所以，如果你不得不忍受这段代码一段时间，我会考虑重构它。我将从为现有代码编写单元测试和集成测试开始，并尝试逐步重构应用程序的某些部分以使用更合理的数据库模型。转换整个应用程序可能需要与原始构建一样多的时间，并且大多数业务人员不会高兴听到添加几个简单的额外功能将需要整个重建 - 所以寻找实用的方法来达到你的目标想去！

于 2012-11-06T13:09:26.537 回答