我一直在尝试创建一个应用程序,其中所有内容都是一个有一系列字段的对象。我已将其抽象到您拥有以下表格的级别:
每个ObjectTemplate都有一系列字段(多对多关系),可以在LinkObjectTemplateField中找到。字段链接到FieldType(多对一关系)。 Field还有一个ObjectTemplateID字段 - 所以我们假设我们有一个名为Section的对象模板,另一个名为Question的对象模板(如调查问卷)。该部分将问题作为调查问卷设计者用于定义哪些问题出现在一个部分中的字段。然后将每个问题与一系列价值观相关联(或者在FieldType' Text'。
的情况下完全没有。到目前为止,我们能够创建字段,字段类型和对象模板。但是我已经意识到实际上所有这三个都可以在上面的表中表示,我也可以杀掉其中一个表(所以我只有ObjectTemplate和LinkObjectTemplateField,其中Field是一个ObjectTemplate并且#39; s拥有权利,因此ObjectTemplate和它自己之间只通过LinkObjectTemplateField链接。
我的目标是为所有对象类型提供一个表结构,无论是现在还是将来。我将有一个类,它根据对象模板获取特定对象的所有字段以及它所期望的字段,并决定如何基于模板显示字段。这似乎变得非常复杂,我一直发现自己感到困惑。我有一个星期的时间来处理这个问题,所以我的问题是:我应该继续这个吗?有没有更好的技术来实现这一点,或者我的方法有任何缺陷?我是否应该坚持使用旧结构(每个对象类型的整个表,与核心详细信息的大多数其他对象类型相同的字段 - 名称,描述,删除等)?
修改
我再次讨论了我的方法并得出以下结论:
答案 0 :(得分:0)
你正在有效地尝试实现EAV的形式,除非你真的需要它所带来的灵活性,否则被视为反模式。
这样的"inner platform"通常是真实的复制品。简而言之:
因此,除非您必须能够更改数据结构而不更改数据库结构,否则只需使用DBMS已经提供的“正常” “表/列/约束......
我的目标是为所有对象类型提供一个表结构,无论是现在还是将来。
嗯,你已经有了内置到你的DBMS:它被称为“数据字典”。是的,你通过CREATE / ALTER / DROP语句而不是INSERT / UPDATE / DELETE来改变它,但在逻辑层面它是类似的东西。
我是否应该坚持使用旧结构(每个对象类型的整个表,与核心详细信息的大多数其他对象类型相同的字段 - 名称,描述,删除等)?
可能。
顺便说一句,如果您有很多常见字段(和/或约束),请考虑将它们放在一个共同的“基础”表中,然后再将"inheriting"表放在其中。