程序员应遵循的数据库设计规则

Question

我们正在开发一个 map 应用程序，它使用 Google Maps API 在 map 上显示点。目前所有的点都是从 MySQL 数据库中获取的(拥有大约 500 万条记录)。目前，所有实体都存储在单独的表中，其属性代表各个属性。

这会带来以下问题:

1. 每次出现新属性时，我们都必须对数据库、应用程序代码和前端进行更改。这一切都很好，但必须为所有实体添加一些属性，所以这时浏览 50 多个不同的表并添加新属性将成为一场噩梦。

2. 无法找到共享任何给定属性的所有实体，例如无法找到所有设有地理系的学校/学院或大学(无需分别查询学校、大学和学院)。

3. 删除属性同样痛苦。

4. 没有用于在单个表中定义属性的标准。同一属性可以不同的名称或数据类型存在于另一个表中。

5. 无法根据属性(与第 2 点相关)链接或分组点。

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

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

例如:

一个名为“university”的实体有 100 多个属性。其他实体(例如医院、银行等)与大学有很多相同的属性，例如 atm 机、 parking 场、自助餐厅等。

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

考虑到这一点，我们正在考虑新设计:

• 每个实体都有单独的表格，其中包含一些基本信息，例如id,name,etc.

• 有 2 个表attribute type 和attribute 来存储属性信息。

• 使用多对多关系将每个实体(或表，如果您愿意)链接到属性。

• 将地址存储在称为地址的不同表中，通过外键链接实体。

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

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

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

感谢您的宝贵时间。

Answer 1

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

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

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

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

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