我们正在开发一个使用Google Maps API在地图上显示点的地图应用程序。所有点目前都是从MySQL数据库中获取的（持有大约5M +记录）。目前，所有实体都存储在具有表示各个属性的属性的单独表中。
这会出现以下问题：
每次有新属性时，我们都必须在数据库，应用程序代码和前端进行更改。这一切都很好但是必须为所有实体添加一些属性，以便在通过50多个不同的表并添加新属性变成噩梦时。
无法找到共享任何特定属性的所有实体，例如无法找到所有拥有地理部门的学校/学院或大学（不分别查询学校，大学和学院）。
删除属性同样痛苦。
没有用于在各个表中定义属性的标准。同一属性可以在另一个表中以不同的名称或数据类型存在。
无法根据点的属性链接或分组点（以某种方式与点2相关）。
我们正在考虑重新设计整个数据库，但如果没有DBA的帮助和缺乏专业的数据库设计经验，我们真的很挣扎。
我们在新设计中遇到的另一个问题是实体之间存在许多共享属性/属性。
例如：
名为“大学”的实体拥有100多个属性。其他实体（例如医院，银行等）与大学有很多共同点，例如自动取款机，停车场，自助餐厅等。
我们真的不想在单独的表中使用属性[然后将它们链接回具有外键的实体]，因为它需要我们手动添加/删除。通用属性也会产生包含50多个属性的组。并非所有记录（即实体）都需要这些属性。
因此，请记住这是我们对新设计的想法：
为每个包含一些基本信息的实体提供单独的表格，例如id，name等等。
有2个表属性类型和属性来存储属性信息。
使用多对多关系将实体（或表格，如果您愿意）链接到属性。
通过外键将地址存储在名为地址链接实体的不同表中。
我们认为这可以让我们在添加，删除或查询属性时更灵活。
然而，这种设计会在获取数据时导致连接数量增加，例如显示给定大学的所有“属性”，我们可能会有20多个连接的查询来获取所有相关属性在一排。
我们迫切需要了解这种设计方法中的一些观点或可能存在的缺陷。
感谢您的时间。
答案 0 :(得分：1)
在没有更具体的例子的情况下试图概括你的问题时，很难真正批评你的方法。如果您想要更深入的分析，请尝试煽动ER diagram。
如果您的数据模型发生了如此大的变化，以至于您不断添加/删除属性并且其中许多属性重叠，那么最好使用EAV。
否则，如果您想维护关系方法但发现与属性有很多重叠，则可以分析实体并查找链接到它们的抽象。
Ex）我的Db有Puppies，Kittens和Walruses都具有hasFur和furColor属性。从3个表中删除这些属性，并创建一个FurryAnimal表，链接到每个表3.
当然，最简单的答案是不要触摸数据模型。而是在基础表上创建Views，用于解决（5），（4）和（2）
答案 1 :(得分：1)