Ste*_*ven 5 sql oracle inheritance database-design
我正在设计一个新的实验室数据库,其中包含许多类型的主要实体.
每个实体的表将包含该实体的所有类型(entity_id,created_on,created_by等)共有的字段.然后,我将使用具体的继承(每个唯一属性集的单独表)来存储所有剩余的字段.
我相信这是每天通过实验室提供的标准数据类型的最佳设计.但是,我们经常会有一些特殊的样本,这些样本通常伴随着发起者想要存储的特定值.
问题:我应该如何建模特殊(非标准)类型的实体？
选项1:用于特殊领域使用的实体价值的
一个表(entity_id,attribute_name,numerical_value)将持有的所有数据进行任何特殊的实体.
+更少的桌子.
- 无法强制要求特定属性.
- 必须将行(数据透视)转换为低效的列.
选项2:严格的具体继承.
为每个单独的特殊情况创建单独的表.
+遵循所有其他规则
- 只有几行的许多表的开销.
选项3:具有不同用户下的特殊表的具体继承.
将所有特殊表放在不同的用户下.
+保持所有特殊和标准表分开.
+更容易在列表中搜索通用标准表而无需搜索所有特殊表.
- 只有几行的许多表的开销.
实际上,您描述的设计(公用表加上特定于子类型的表)称为类表继承.
具体表继承将在子类型表中复制所有公共属性,并且您现在没有超类型表.
我强烈反对EAV.我认为它是一个SQL反模式.它似乎是一个优雅的解决方案,因为它需要更少的表,但你后来为自己设置了很多头痛.你发现了一些缺点,但还有很多其他缺点.恕我直言,只有当您引入新的子类型时绝对不能创建新表,或者如果您有无限数量的子类型(例如,用户可以定义新的属性)时,才能正确使用EAV .
你有很多子类型,但仍然是有限数量的子类型,所以如果我在做这个项目,我会坚持使用类表继承.每个子类型可能只有几行,但至少可以保证每个子类型中的所有行都有相同的列,NOT NULL如果需要可以使用,可以使用SQL数据类型,可以使用参照完整性约束等从关系角度来看,它比EAV更好.
您未提及的另一个选项称为序列化LOB.也就是说,为自定义属性的半结构化集合添加BLOB列.在该列中存储XML,YAML,JSON或您自己的DSL.您将无法使用SQL轻松解析BLOB中的各个属性,您必须将整个BLOB提取回应用程序并在代码中提取单个属性.所以在某些方面它不太方便.但如果这满足您对数据的使用,那么这没有任何问题.