实体属性值模型（EAV）以及如何使用cfml实现它？
我正在尝试弄清楚如何在 Coldfusion 中实现这种关系。另外，如果有人知道这种关系的名称，我很想知道。
我正在尝试创建棕色桌子。
从值重新创建表不是问题，我几天来一直困扰的问题是如何创建编辑环境。
我想我应该有一个包含所有租户和 TenantValues（与我正在编辑的 TenantID 匹配的 TenantValues）的表，并且还应该有空值（绿色表）
还有其他建议吗？
I'm trying to figure out how to implement this relationship in coldfusion. Also if anyone knows the name for this kind of relationship I'd be curious to know it.
I'm trying to create the brown table.
Recreating the table from the values is not the problem, the problem that I've been stuck with for a couple of days now is how to create an editing environment.
I'm thinking that I should have a table with all the Tenants and TenantValues (TenantValues that match TenantID I'm editing) and have the empty values as well (the green table)
any other suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这种关系的名称称为实体属性值模型 (EAV)。在您的情况下，
Tenant、TenantVariable、TenantValues分别是实体表、属性表和值表。 EAV 试图允许运行时定义或实体，并且在我支持内容管理系统的经验中最常见。它被称为反模式数据库模型，因为你会丢失某些RDBMS 具有优点，但也有缺点，例如在删除或保存时必须锁定多个表。通常，合适的持久性替代方案是 NoSQL 解决方案，例如 Couch。至于编辑，我通常看到的范例是删除给定 ID 的所有值记录并插入循环内，然后更新实体表记录。 在事务内部执行此操作以确保一致性。这种方法的结果是它一定比增量检测算法更容易计算出来。另一种选择是使用 MERGE 语句（如果您的数据库支持）。
The name of this relationship is called an Entity Attribute Value model (EAV). In your case
Tenant,TenantVariable,TenantValuesare the entity, attribute and value tables, respectively. EAV is attempt to allow for the runtime definition or entities and is most found in my experience backing content managements systems. It has been referred to an as anti pattern database model because you lose certain RDBMS advantages, while gaining disadvantages such as having to lock several tables on delete or save. Often a suitable persistence alternative is a NoSQL solution such as Couch.As for edits, the paradigm I typically see is deleting all the value records for a given ID and inserting inside a loop, and then updating the entity table record. Do this inside of a transaction to ensure consistency. The upshot of this approach is that it's must easier to figure out than delta detection algorithm. Another option is using the MERGE statement if your database supports it.
您可能需要考虑使用 RDF 三重存储来解决此问题。它是关系数据库的替代方案，特别适合稀疏分类数据。数据表示为三元组 - 有向图边，由主语、宾语和描述连接它们的属性的谓词组成：
数据集中的一些示例三元组看起来类似于：
RDF 三元组存储提供 SPARQL 查询语言来从存储中检索数据，就像使用 SQL 一样。
You may want to consider an RDF Triple Store for this problem. It's an alternative to Relational DBs that's particularly good for sparse categorical data. The data is represented as triples - directed graph edges consisting of a subject, an object, and the predicate that describes the property connecting them:
Some example triples from your data set would look something like:
RDF triple stores provide the SPARQL query language to retrieve data from your store much like you would use SQL.