Question

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

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

将移动设置反规范化并存储在另一个表中有多糟糕？或者更好的存储设置方法？这些属性变得笨拙，难以在表格中修改/找到。

Answer 1

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

@Alexander Sobolev建议EAV model。由于您需要多次连接以获取实体的所有值，因此这会导致最大的灵活性，性能和复杂性。您通常解决这些问题的方法是将所有实体元数据保留在内存中（即tblProperties），这样您就不会在运行时加入它。并且，将值（即tblProjectProperties）非规范化为离开根表的CLOB（即XML）。因此，您只使用值表进行查询和排序，而不是实际检索数据。此外，您通常最终还会按ID缓存实际实体，因此每次都不需要反序列化。您遇到的问题是实体及其元数据的缓存失效。总的来说，这是一个非常重要的方法。

我要做的是使用鉴别器/类型列创建一个单独的表，可能不止一个，具体取决于您的数据：

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

将root_id和type_id组合成唯一，其中type_id代表移动设备 - 假设我的示例中有一个单独的查找表。

Answer 2

在其他表中存储移动部分时，没有错误。这甚至可以带来一些经济效益，这取决于这些信息的使用量。

您可以存储在另一个表中，或者使用包含三个表的更复杂的版本。一个是你的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 - ＆gt; tblProject.uid 和外键tblProjectProperties.propertyUid - ＆gt; tblProperties.id

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

数据库设计，大量参数，非规范化？

2 个答案: