Database design rules to follow for a programmer
我们正在开发一个映射应用程序，它使用谷歌地图API在地图上显示点。所有点目前都是从一个MySQL数据库中获取的(保存了大约500多条记录)。当前，所有实体都存储在单独的表中，这些表的属性表示各个属性。
出现以下问题：
每次有新的属性时，我们都必须对数据库、应用程序代码和前端进行更改。这一切都很好，但必须为所有实体添加一些属性，因此当您通过50多个不同的表并添加新属性时，这将成为一场噩梦。
找不到所有共享任何给定财产的实体，例如找不到所有拥有地理系的学校/学院或大学(不单独查询学校、大学和学院)。
移除财产同样痛苦。
没有在单个表中定义属性的标准。同一属性可以在另一个表中以不同的名称或数据类型存在。
无法根据点的属性(不知何故与点2相关)链接或分组点。
我们正在考虑重新设计整个数据库，但如果没有DBA的帮助和专业的DB设计经验，我们真的很困难。
新设计面临的另一个问题是，实体之间有很多共享的属性/属性。
例如：
一个名为"大学"的实体有100多个属性。其他实体(如医院、银行等)与大学具有相当多的属性，例如ATM机、停车场、自助餐厅等。
我们不希望在单独的表中有属性[然后将它们链接回带有外键的实体]，因为它需要我们手动添加/删除。此外，归纳属性还将导致包含50多个属性的组。并非所有记录(即实体)都需要这些属性。
因此，记住这一点，以下是我们对新设计的看法：
每个实体都有单独的表，其中包含一些基本信息，例如ID、名称等。
有两个表属性类型和属性来存储属性信息。
使用多对多关系将每个实体(或表，如果愿意)链接到属性。
通过外键将地址存储在称为地址链接实体的不同表中。
我们认为这将使我们在添加、删除或查询属性时更加灵活。
然而，这种设计会导致在获取数据时连接的数量增加，例如，为了显示给定大学的所有"属性"，我们可能会使用20多个连接进行查询，以便在一行中获取所有相关的属性。
我们迫切需要了解这种设计方法中的一些观点或可能的缺陷。
谢谢你的时间。
1不能是问题。有一个地方可以定义对象。其他的一切都是从中产生的。只需重构代码，直到出现这种情况。
2通过一个元模型来解决，您可以在其中描述哪些属性。这可能也是1所需要的。
您可能希望通过在一个gemstone面向对象的数据库上用smalltalk和seaside编程来完全避免这个问题。然后，您可以只拥有带有集合的对象，而不需要这么多连接。
在试图概括你的问题时，如果没有更具体的例子，很难真正地批评你的方法。如果你想做更深入的分析，试着做一个ER图。
如果您的数据模型变化太大以至于您不断地添加/删除属性，并且其中许多属性重叠，那么您最好使用EAV。
否则，如果您想要维护一种关系方法，但是发现与属性有很多重叠，那么您可以分析实体并寻找与它们链接的抽象。
我的数据库有小狗、小猫和海象，它们都有hasfur和furcour属性。从3个表中删除这些属性，并创建一个furryanimal表，链接到这3个表中的每一个。
当然，最简单的答案是不要触摸数据模型。相反，在基础表上创建视图，您可以使用这些视图来处理(5)、(4)和(2)