给定表格tblProject。这有无数的属性。例如，宽度，高度等。几十个。
我正在添加一个新模块，可让您为移动设备的项目指定设置。这是一个 1-1 的关系，所以所有的移动设置都应该存储在 tblProject 中。但是，列表越来越大，属性之间会有一些歧义（IE，我必须在所有移动字段前加上 MOBILE 前缀，以免 Mobile_width 与宽度混淆）。
将移动设置非规范化并将其存储在另一个表中有多糟糕？还是存储设置的更好方法？属性变得笨拙且难以在表格中修改/查找。
【问题讨论】：
标签： database database-design denormalization
我想回应@Alexander Sobolev 的建议并提供我自己的建议。
@Alexander Sobolev 建议使用EAV model。这以最大的灵活性换取了较差的性能和复杂性，因为您需要多次加入才能获得实体的所有值。您通常解决这些问题的方法是将所有实体元数据保存在内存中（即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 并仅存储给定项目真正需要的属性。上面的模式为您提供了一些灵活性。您可以为不同的项目类型创建一些视图，并使用它来避免用户选择中的过多联接。
【讨论】：