程序员要遵循的数据库设计规则答案

【问题标题】：Database design rules to follow for a programmer程序员要遵循的数据库设计规则
【发布时间】：2011-05-19 08:28:10
【问题描述】：

我们正在开发一个地图应用程序，该应用程序使用 Google Maps API 在地图上显示点。目前所有点都是从 MySQL 数据库中获取的（保存大约 5M + 记录）。目前，所有实体都存储在单独的表中，其属性代表各个属性。

这会带来以下问题：

每次出现新属性时，我们都必须对数据库、应用程序代码和前端进行更改。这一切都很好，但是必须为所有实体添加一些属性，这样就变成了遍历 50 多个不同的表并添加新属性的噩梦。
无法找到共享任何给定属性的所有实体，例如无法找到所有有地理系的学校/学院或大学（无需分别查询学校、大学和学院）。
删除属性同样痛苦。
没有用于在单个表中定义属性的标准。相同的属性可以在另一个表中以不同的名称或数据类型存在。
无法根据属性（在某种程度上与第 2 点相关）链接或分组点。

我们正在考虑重新设计整个数据库，但没有 DBA 的帮助和缺乏专业的数据库设计经验，我们真的很挣扎。

我们在新设计中面临的另一个问题是实体之间有很多共享属性/属性。

例如：

一个名为“university”的实体有 100 多个属性。其他实体（例如医院、银行等）与大学共享很多属性，例如自动取款机、停车场、自助餐厅等。

我们真的不想在单独的表中拥有属性[然后将它们链接回带有外键的实体]，因为这需要我们手动添加/删除。此外，泛化属性将导致包含 50 多个属性的组。并非所有记录（即实体）都需要这些属性。

因此，牢记这一点，这就是我们对新设计的想法：

我们认为这将使我们在添加、删除或查询属性时更加灵活。

然而，这种设计将导致在获取数据时增加连接数，例如显示给定大学的所有“属性”，我们可能有一个包含 20 多个连接的查询来获取所有相关属性在一行中。

我们迫切需要了解这种设计方法中的一些意见或可能存在的缺陷。

感谢您的宝贵时间。

【问题讨论】：

【解决方案1】：

在没有更多具体示例的情况下试图概括您的问题，很难真正批评您的方法。如果您想要更深入的分析，请尝试发送ER diagram。

如果您的数据模型变化如此之大以至于您不断添加/删除属性并且其中许多属性重叠，那么您最好使用EAV。

否则，如果您想保持关系方法但发现与属性有很多重叠，您可以分析实体并寻找链接到它们的抽象。

Ex) 我的 Db 有小狗、小猫和海象，它们都具有 hasFur 和 furColor 属性。从 3 个表中删除这些属性，并创建一个链接到这 3 个表的 FurryAnimal 表。

当然，最简单的答案是不接触数据模型。相反，在可用于处理 (5)、(4) 和 (2) 的基础表上创建 Views

【讨论】：

当然，EAV 可能是你见过的表现最差的噩梦。
很抱歉没有早点回复您。数据模型确实发生了很大变化，我们最终会频繁地添加或删除属性。此外，我们必须允许用户添加自定义属性，这就是我考虑混合 EAV 结构的原因。顺便说一句，我已经用一些例子更新了这个问题。

【解决方案2】：

1 不是问题。有一个地方可以定义您的对象。其他一切都是从中生成/派生的。只需重构您的代码，直到出现这种情况。

2 通过使用元模型来解决，您可以在其中描述哪些属性在哪里。这可能也是 1 所需要的。

您可能希望通过在 Smalltalk 中使用 Seaside 在 Gemstone 面向对象的数据库上进行编程来完全避免该问题。然后你可以只拥有带有集合的对象，而不需要那么多连接。

【讨论】：