给定表tblProject
。这有无数的属性。例如,宽度、高度等。几十个。
我正在添加一个新模块,可让您为移动设备的项目指定设置。这是 1-1 的关系,所以所有的移动设置都应该存储在 tblProject 中。但是,列表变得越来越大,属性之间会有一些歧义(IE,我必须在所有移动字段前加上 MOBILE 前缀,这样 Mobile_width 就不会与宽度混淆)。
将移动设置非规范化并将其存储在另一个表中有多糟糕?还是存储设置的更好方法?属性变得笨拙且难以在表中修改/查找。
给定表tblProject
。这有无数的属性。例如,宽度、高度等。几十个。
我正在添加一个新模块,可让您为移动设备的项目指定设置。这是 1-1 的关系,所以所有的移动设置都应该存储在 tblProject 中。但是,列表变得越来越大,属性之间会有一些歧义(IE,我必须在所有移动字段前加上 MOBILE 前缀,这样 Mobile_width 就不会与宽度混淆)。
将移动设置非规范化并将其存储在另一个表中有多糟糕?还是存储设置的更好方法?属性变得笨拙且难以在表中修改/查找。
我想回应@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
例如代表移动设备的地方 - 在我的示例中假设一个单独的查找表。
将移动部分存储在其他表中没有什么不好。这甚至可以带来一些经济性,这取决于这些信息的使用量。
您可以存储在另一个表中,或者使用包含三个表的更复杂的版本。一个是您的 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 并仅存储给定项目真正需要的属性。上面的模式为您提供了一些灵活性。您可以为不同的项目类型创建一些视图,并使用它来避免用户选择中的过多连接。