如何设计一个模式，其中一个表的列没有固定

我试图设计一个模式，其中一个表的列是不固定的。例如：我有一个Employee表，其中表的列不固定并且各不相同（Employee的属性不固定且不同）。需要频繁添加新的属性/列。在雇员表如何设计一个模式，其中一个表的列没有固定

空列本身即不归
而不是添加空列的，这些列分离出来，在他们各自的表例如：如果地址是要添加，然后创建表的地址栏[EmployeeId，AddressValue]。
创建表ExtensionColumnName [EMPLOYEEID，的ColumnName]和ExtensionColumnValue [EMPLOYEEID，ColumnValue]。 ExtensionColumnName将ColumnName作为“Address”，ExtensionColumnValue将ColumnValue作为地址值。

Employee表
雇员
名称

ExtensionColumnName表
ColumnNameId
雇员
的ColumnName

ExtensionColumnValue表
雇员
ColumnNameId
上校umnValue

有一个缺点是模式随每个新属性而改变的前两种方法。请注意，添加一个新属性是很常见的，也是一项要求。

我不知道这是好还是不好的设计。如果有人有类似的决定作出，请给上之类的东西外键/数据的完整性，索引，性能，洞察报告等

来源

2010-05-28 hIpPy

我建议使用数字两个和三个的组合。在可能的情况下，为地址等标准关联建立模型表。这是最理想的方法...

但对于不断变化不能被归纳为这样的逻辑分组值，可使用除了两个表的EMPLOYEES表：

EMPLOYEE_ATTRIBUTE_TYPE_CODES（两列，employee_attribute_type_code和说明）
EMPLOYEE_ATTRIBUTES （三列：EMPLOYEE_ID外键的员工，employee_attribute_type_code外键EMPLOYEE_ATTRIBUTE_TYPE_CODES，和值）

在EMPLOYEE_ATTRIBUTES，设置主键来进行的：

EMPLOYEE_ID
employee_attribute_type_code

这将停止重复的属性相同的员工。

来源

2010-05-28 20:43:48

OMG小马，我最终提出了架构。我对这种模式的问题感兴趣。例如：如果EMPLOYEE_ATTRIBUTES中的VALUE列是一个ID（某个其他表的主键），那么它就成了一个问题。这可以通过具有单独的元表来表示，该表表示这种属性是查找和对应的查找表名。这将涉及一些动态的SQL或反射，我失去了类型安全。 – hIpPy 2010-06-04 14:55:10

结合您ExtensionColumn表到一个

Property: 
    EmployeeID foreign key 
    PropertyName string 
    PropertyValue string

如果使用用于在所有对象表中分配主键的单调序列，则单个属性表可以保存所有对象的属性。

来源

2010-05-28 20:43:27

有一种模式，称为观察模式。

有关说明，请参阅这些问题/回答：one，two，three。

在一般情况下，是这样的：

例如，科目员工，公司和动物都可以有观察名称（性状），科目员工和动物可以有观察重量（测量）和主题啤酒瓶可以有观察标签（性状）和体积（测量）。这一切都适合模型。

来源

2010-05-28 20:44:11

查看NoSQL数据库的当前作物可能很有用，它允许您为每个记录存储任意组的键值对。

我建议你了解CouchDB，MongoDB中，Lucene的，等等

如果经常架构更改在SQL数据库这最终在一场噩梦，尤其是与报告。

将所有内容放入（rowId，key，value）三元组中是非常灵活的，但由于记录数量巨大而变慢。

ERP供应商的做法只是让他们确定的字段的模式，并在固定的命名列中添加大量的“弹性域”（即20个数字，20个字符串等），并使用查找表来查看哪个flexcolumn对应于什么。这为基于静态模式的未来提供了一些灵活性。

来源

2010-05-28 20:44:20

为永远属性添加列不是“大男孩怎么做”，主要是因为数据库对每个表允许的列数有严格的限制（数据类型曾经是一个问题，但现在并没有给出如何便宜的硬盘驱动器是）。坦率地说，具有20列以上的表很难使用它们的INSERT＆UPDATE语句...... – 2010-05-28 20:53:29

我在考虑在Oracle EBS中使用10000+表模型时使用“Big Boys”这个术语，而非松散地使用舌头。每个其他表格都填充了这些占位符列。就我个人而言，我觉得它非常难看，但显然他们在那里存活了20多年。我想这是那些丑陋的，实用的解决方案，在大多数情况下都可以正常工作。 – 2010-05-28 22:10:41

如果您像所说的那样会频繁添加新属性，那么EAV数据模型可能适合您。

来源

2010-05-28 21:00:53

我会使用1和2的组合。如果您要频繁添加属性，我认为您不需要处理数据要求。

我认为一些被添加的属性属于另一个表。如果您不断添加像java认证，asp认证等分类，那么您需要一个认证表。这可能与列出可用认证的认证代码表有关系。

像管理器这样的属性可能是属性或关系表。如果员工之间存在多重关系，则考虑具有相关类型的关系表。具有矩阵管理结构的组织将需要一个关联表。

地址和电话号码通常放在单独的表格中。像employee_id，address_type这样的地址键是适当的。如果需要历史记录，请向该密钥添加一个start_date列。

如果您保留历史记录，我建议在适当的列上使用start_date和end_date列。当'start_date < =日期被认为是< end_date'为真时，我尝试使用记录处于活动状态的关系。像重量，眼睛颜色等属性

来源

2010-05-28 21:27:14 BillThor

如何设计一个模式，其中一个表的列没有固定

回答

相关问题