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_idtype_idtype_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 回答