我很想知道创建由数据库支持的自定义系统的优缺点，如下所述：
它有6个表支持它。
实体：让我们说，任何可以存在的“物理”物品，并且存有针对它的详细信息 （希尔顿酒店，Tony Taxi，One Bar）
实体类型：实体的分组/类型 （酒吧，酒店，餐厅）
元数据：描述或属于实体项目的任何详细信息 （IR232PH，foo @ bar.com，555-555-555）
元数据类型：元数据的分组/类型 （邮政编码，电话，电子邮件，地址）
实体关系：将任何实体项目分组到另一个实体项目的能力 （Entity1-Entity2，Entity3）
实体关系类型：实体关系的分组/类型。
我可以看到这个模型对于相似但不总是具有相同数量的属性的实体是如何有益的。
对于所描述的实体，使用它的利弊是什么？
使用它还可以存储更多标准实体（如系统用户）的利弊是什么？
你是否会接受新闻和博客文章？
答案 0 :(得分：3)
这是非常主观的，但在我将抽象阶梯提升到您建议的位置之前，我宁愿将我的应用程序编码为使用DDL修改数据库模式以匹配其使用的实际实体的具体方面，而不是抽象静态模式，以便能够存储任何潜在实体的数据。
在某种程度上，有点滑稽，恕我直言，你所建议的已经完成了....它被称为关系数据库。每个RDBMS都是一个软件工具，旨在能够以精确建模这些实体及其之间关系的方式对任何可能的实体集及其属性进行建模。
答案 1 :(得分：3)
虽然您当然可以将数据存储在这样的数据模型中，但至少存在一些问题（<至少>）。
第一个问题是控制数据。描述“酒店”时，必须定义的属性和元数据集是什么？可以合法地为酒店输入哪些元数据类型？与此相关的是“当我从列表中删除酒店时，我还需要删除什么”？当我从列表中删除所有酒店时（我再也不想存储有关酒店的信息），还有什么我必须删除的？很可怕（很可怕？）很容易将各种杂散无关的未引用数据输入数据库。
第二个问题是检索数据。假设我想知道有关特定酒店的所有信息？我该如何编写查询？实际上，即使插入数据也很难，但选择它是更难的。如果我只想要三个属性，那就很容易 - 如果酒店实际上拥有它们。如果酒店只有三个中指定的两个，那就更难了。但假设酒店有30个属性，这并不是很多。然后非常困难。
您所描述的是称为EAV或Entity-Attribute-Value数据模型的模型的加强版本。人们普遍认为这是一个“坏主意”，因为这是一个普遍的想法。
答案 2 :(得分：1)
您所描述的也称为三重商店。三元组是主语 - 宾语谓词（Hotel HAS Rooms，Joe Likes HotelX等）。有一些机制可以运行这些东西（三元组实现），控制数据（例如使用本体）和查询它们（例如SPARQL语言）。然而，这都是相当尖端的东西，并且已知具有可扩展性问题。然而，结合NoSQL方法（在大型文档商店中索引所有酒店等），这是一个值得关注的有趣领域。