1

目前的结构如下:

Table RowType:    RowTypeID

Table RowSubType: RowSubTypeID
                  FK_RowTypeID

Table ColumnDef:  FK_RowTypeID
                  FK_RowSubTypeID (nullable)

简而言之,我将列定义映射到行。在某些情况下,这些行具有子类型,这些子类型将具有特定于它们的列定义。或者,我可以将那些特定于子类型的列定义从它们自己的表中挂起,或者我可以将 RowType 和 RowSubType 中的数据组合到一个表中并使用单个 ID,但我不确定是否是更好的解决方案(如果有的话,我会倾向于后者,因为我们最终会为给定的 RowType/RowSubType 提取 ColumnDefs)。

现在的设计 SQL 是不是亵渎神灵?

如果我保留当前结构,如果在 ColumnDef 中指定了 RowSubTypeID,我如何维护它必须对应于 RowTypeID 指定的 RowType?我应该尝试使用触发器来强制执行此操作,还是我错过了可以解决问题的简单重新设计?

4

1 回答 1

4

您遇到的问题是第四范式

这是解决方案:

Table RowSubType:       RowSubTypeID
                        FK_RowTypeID
                        UNIQUE(FK_RowTypeID, RowSubTypeID) 

Table ColumnDef:        ColumnDefID
                        FK_RowTypeID
                        UNIQUE(ColumnDefID, FK_RowTypeID) 

Table ColumnDefSubType: FK_ColumnDefID   } compound foreign key to ColumnDef
                        FK_RowTypeID     }   } 
                        FK_RowSubTypeID      } compound foreign key to RowSubType

您只需在 ColumnDefSubType 表中为具有行子类型的列创建一行。但是所有引用都受到限制,因此您无法创建异常。

But for what it's worth, I agree with @Seth's comment about possible over-engineering. I'm not sure I understand how you're using these column defs and row types, but it smells like the Inner-Platform Effect anti-pattern. In SQL, just use metadata to define metadata. Don't try to use data to create a dynamic schema.

See also this excellent story: Bad CaRMa.


Re your comment: In your case I'd recommend using Class Table Inheritance or Concrete Table Inheritance. This means defining a separate table per subtype. But each column of your original text record would go into the respective column of the subtype table. That way you don't need to have your rowtype or rowsubtype tables, it's implicit by defining tables for each subtype. And you don't need your columndefs table, that's implicit by the columns defined in your tables.

See also my answer to Product table, many kinds of product, each product has many parameters or my presentation slides Practical Object-Oriented Models in SQL.

于 2010-06-02T17:40:26.653 回答