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

发布于 2024-10-17 10:56:10 字数 269 浏览 2 评论 0原文

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

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

只有一腔孤勇 2024-10-24 10:56:10

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

@Alexander Sobolev 建议使用 EAV 模型。这会牺牲最大的灵活性，但性能和复杂性都很差，因为您需要多次加入才能获取实体的所有值。解决这些问题的通常方法是将所有实体元数据保留在内存中（即 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 代表移动设备 - 假设我的示例中有一个单独的查找表。

I want to respond to @Alexander Sobolev's suggestion and provide my own.

@Alexander Sobolev suggests an EAV model. This trades maximum flexibility, for poor performance and complexity as you need to join multiple times to get all values for an entity. The way you typically work around those issues is keeping all the entity meta data in memory (i.e. tblProperties) so you don't join to it at runtime. And, denormalize the values (i.e. tblProjectProperties) as a CLOB (i.e. XML) off the root table. Thus you only use the values table for querying and sorting, but not to actually retrieve the data. Also you usually end up caching the actual entities by ID as well so you don't have the expense of deserialization each time. Issues you run into the are cache invalidation of the entities and their meta data. So overall a non trivial approach.

What I would do instead is create a separate table, perhaps more than one depending on your data, with a discriminator/type column:

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

Make the unique a combination of root_id and type_id, where type_id would be representative of mobile for instance - assuming a separate lookup table in my example.

回复收藏 0 原文

恰似旧人归 2024-10-24 10:56:10

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

您可以存储在另一个表中，或者使用具有三个表的更复杂的版本。一种是您的 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。项目Uid -> tblProject.uid
和外键 tblProjectProperties.propertyUid -> tblProperties.id

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

There is nothing bad in storing mobile section in other table. This could even carry some economy, this depends on how much this information is used.

You can store in another table or use even more complicated version with three tables. One is your tblProject, one is tblProperties and one is 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)
)

with foreign key tblProjectProperties. ProjectUid -> tblProject.uid
and foreign key tblProjectProperties.propertyUid -> tblProperties.id

Thing is if you have different types of projects wich use different properties, you have no need to store all these unused null and store only properties you really need for given project. Above schema gives you some flexibility. You can create some views for different project types and use it to avoid too much joins in user selects.

回复收藏 0 原文

~没有更多了~