1

给定表tblProject。这有无数的属性。例如，宽度、高度等。几十个。

我正在添加一个新模块，可让您为移动设备的项目指定设置。这是 1-1 的关系，所以所有的移动设置都应该存储在 tblProject 中。但是，列表变得越来越大，属性之间会有一些歧义（IE，我必须在所有移动字段前加上 MOBILE 前缀，这样 Mobile_width 就不会与宽度混淆）。

将移动设置非规范化并将其存储在另一个表中有多糟糕？还是存储设置的更好方法？属性变得笨拙且难以在表中修改/查找。

4

2 回答 2

2

我想回应@Alexander Sobolev 的建议并提供我自己的建议。

@Alexander Sobolev 建议使用EAV 模型。这以最大的灵活性换取了较差的性能和复杂性，因为您需要多次加入才能获得实体的所有值。您通常解决这些问题的方法是将所有实体元数据保存在内存中（即tblProperties），这样您就不会在运行时加入它。并且，将值（即tblProjectProperties）非规范化为根表之外的 CLOB（即 XML）。因此，您只使用 values 表进行查询和排序，而不是实际检索数据。此外，您通常最终也会按 ID 缓存实际实体，这样您就不必每次都花费反序列化的费用。您遇到的问题是实体及其元数据的缓存失效。因此，总体而言，这是一种不平凡的方法。

我会做的是创建一个单独的表，根据您的数据可能不止一个表，并带有一个鉴别器/类型列：

create table properties (
    root_id int, 
    type_id int,
    height int
    width int
    ...etc...
)

使唯一的组合root_id和type_id，type_id例如代表移动设备的地方 - 在我的示例中假设一个单独的查找表。

于 2011-02-14T14:49:44.367 回答
1

将移动部分存储在其他表中没有什么不好。这甚至可以带来一些经济性，这取决于这些信息的使用量。

您可以存储在另一个表中，或者使用包含三个表的更复杂的版本。一个是您的 tblProject，一个是 tblProperties，一个是 tblProjectProperties。

create table tblProperties (
id int autoincrement(1,1) not null,
prop_name nvarchar(32),
prop_description nvarchar(1024)
)

create table tblProjectProperties
(
   ProjectUid int not null,
   PropertyUid int not null,
   PropertyValue nvarchar(256)
)

带有外键 tblProjectProperties。ProjectUid -> tblProject.uid 和外键 tblProjectProperties.propertyUid -> tblProperties.id

问题是，如果您有不同类型的项目使用不同的属性，则无需存储所有这些未使用的 null 并仅存储给定项目真正需要的属性。上面的模式为您提供了一些灵活性。您可以为不同的项目类型创建一些视图，并使用它来避免用户选择中的过多连接。

于 2011-02-14T12:53:58.857 回答