我们正在MS Access 2010中设计一个小型数据库，我们有3个主要属性 让我们举例说，我们有国家，州和口味。我们没有为每个属性设计主表，而是提出了一个如下表
ID Value Attribute
1 USA Country
2 UK Country
3 Illionis State
4 Wisconsin State
5 Sweet Taste
6 Sour Taste
我们正在使用自我加入并获得所需内容。 有没有人认为，这不是一个好的数据库设计，如果是，请解释
答案 0 :(得分：1)
反对的原因：
1）额外的存储空间，用于存储指示其类型的字段（当具有多个表时，由每个表上的主键取消，但是您需要将该类型存储为（小）整数类型，不是字符串类型）。
2）不适用于某些类型的字段的额外存储空间（如果以上不仅仅是示例，则为N / A，并且不会有更多字段，但我会质疑数据库的其余部分设计和可扩展性总是值得考虑的。）
3）降低性能以选择适用的行。
4）Attribute显然需要一个索引（否则（3）是性能杀手），因此 - 更新和删除语句的性能降低。
5）数据库设计错误 - 不要将不属于的概念组合在一起
修改
6）数据库完整性 - 阻止您将无效数据插入Attribute字段的原因。不可否认，你可以拥有另一个带有属性的表，并使Attribute成为该表的外键，这有点混乱，并且有时会弄清楚有时会发生什么。
7）外键 - 这样做只会是一团糟，不要太提及你不能强制执行数据库完整性和可能的速度影响。
8）可视化 - 任何表格图都必须手动绘制或编辑，因为自动生成工具（很可能）无法解释此类设计。
答案 1 :(得分：0)
如果我需要按国家/地区获取州名单，我该怎么做？使用您的设计，除了添加额外的表之外，您无法做到这一点。如果您拆分为实体类型，例如Country，AdministrativeDivision和Taste，您可以为每个实体存储适当的属性，而不是复杂的连接表。生成的SQL更易于阅读和调试。
没有理由尝试＆＃34;优化＆＃34;通过最小化表的数量。任何现代数据库引擎都不会受到额外表的性能损失。实际上，您的设计可能会导致性能下降。根据您尝试阻塞到该表中的不同实体的数量，您可能最终使其变得如此之大以至于整个表不能适合内存，从而迫使数据库在执行选择和连接时从磁盘进行寻呼表。一个好的经验法则可能是，如果您无法合理地猜测数据库可能使用哪种查询计划来获取您请求的数据，只需遵循可接受的SQL最佳实践。
有一种情况我可以想到这个设计可以接受的地方，如果您需要为用户提供商店以便在运行时添加他们自己的类别和值，那么就是这样。