1

我们正在 MS Access 2010 中设计一个小型数据库，我们有 3 个主属性，例如，我们有 Country、State 和 Tastes。我们没有为每个属性设计主表，而是想出了一个如下表

ID  Value       Attribute
1   USA         Country
2   UK          Country
3   Illionis    State
4   Wisconsin   State
5   Sweet       Taste
6   Sour        Taste

我们正在使用自连接并获得所需的内容。有没有人认为，这不是一个好的数据库设计，如果是，请解释

4

2 回答 2

1

反对理由：

1）额外的存储空间来存储指示它是什么类型的字段（在有多个表时由每个表上的主键取消，但是您需要将类型存储为（小）整数类型，而不是字符串类型）。

2）为不适用于某些类型的字段提供额外的存储空间（如果以上不仅仅是示例，则不适用，并且不会有更多字段，但是我质疑您的数据库设计的其余部分，并且可扩展性总是值得考虑的）。

3) 降低性能以选择适用的行。

4）显然需要索引Attribute（否则（3）是性能杀手），因此 - 降低了更新和删除语句的性能。

5) 糟糕的数据库设计——不要组合不属于一起的概念

编辑：

6) 数据库完整性 - 是什么阻止您将无效数据插入到Attribute字段中。诚然，您可以拥有另一个带有属性的表并Attribute为该表创建一个外键，这有时会有点混乱和令人困惑。

7）外键 - 这样做只会一团糟，更不用说你不能强制数据库完整性和可能的​​速度影响。

8) 可视化——任何表格图都必须手动绘制或编辑，因为自动生成工具（很可能）无法解释这种类型的设计。

于 2013-02-01T13:43:22.853 回答
0

如果我需要按国家/地区获取州列表，我该怎么做？对于您的设计，除了添加一个额外的表格之外，您无法做到这一点。如果您拆分为实体类型，例如 Country、AdministrativeDivision 和 Taste，您可以为每个实体存储适当的属性，而不是复杂的连接表。生成的 SQL 更易于阅读和调试。

确实没有理由尝试通过最小化表的数量来“优化”。任何现代数据库引擎都不会受到额外表的性能损失。您的设计实际上可能会触发性能损失。根据您尝试塞入该表的不同实体的数量，您最终可能会使其变得如此之大以至于整个表无法放入内存，从而在对该表执行选择和连接时强制数据库从磁盘分页。一个好的经验法则可能是，如果您无法合理猜测数据库可能使用什么查询计划来获取您请求的数据，则只需遵循公认的 SQL 最佳实践即可。

在一种情况下，我可以想到这种设计可以接受的地方，那就是您需要为用户提供一个商店，以便在运行时添加他们自己的类别和值。

于 2013-02-01T13:57:37.797 回答