sql - 一个大的域表被认为是糟糕的设计吗？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this question




我必须向正在维护的 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 方法来存储和检索数据。

我个人喜欢这两种方法的第二种方法 main reasons :

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

可以很自然地使用外键约束来验证数据，
如果你有一张 table ，这可能是不可行的，也许命名为
“通用域”。并不是完全不可能，只是
使用约束困惑

我倾向于认为，如果您没有某种严格的比率来帮助决定选择哪种方式，那么您最终将每次都走快速而肮脏的道路。

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

Answer 1

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

还要考虑到您的“好”设计需要架构更改、新代码和测试，所有这些都是昂贵的并且带有风险。