问题标签 [denormalization]

我正处于开发数据库驱动系统的早期阶段，系统的最大部分围绕继承类型的关系展开。有一个包含大约 10 列的父实体，并且将有大约 10 个从父实体继承的子实体。每个子实体将有大约 10 列。我认为给父实体提供自己的表并给每个子实体自己的表是有意义的 - 每个子类的表结构。

今天，我的用户要求查看我创建的系统的结构。他们对每个子类的表结构的想法犹豫不决。他们更喜欢一个大约 100 列的大表，因为他们更容易执行自己的自定义查询。

为了用户，我应该考虑对数据库进行非规范化吗？

我希望你能帮助找到一个问题的答案，这个问题将成为工作中反复出现的主题。这涉及将 RDBMS 表中的数据非规范化为具有跨列重复组（共享域和含义）的平面文件格式。不幸的是，这是不可避免的。

这是我需要的转换的一个非常简化的示例：

这将变成：

来自 的每个条目TABLE A将在输出平面文件中有一行，来自 的每个相关字段一列TABLE B。输出文件中的列对于从TABLE B.

我意识到这将创建一个非常宽的文件，但这是一个要求。我看过 MapForce 和 Apatar，但我认为这个问题太奇怪了，或者我无法正确使用它们。

我的问题：是否已经有一种工具可以实现这一点，或者我应该从头开始开发一个工具（我不想重新发明轮子）？

好的，假设有这个数据库模式（关系）：

表 User 由 Authlogic 生成。

我有 2 个注册用户，每个人都有他的客户，等等。。使用 Authlogic，我可以只允许经过身份验证的用户访问控制器/视图。没关系，这就是 Authlogic 的用途。

现在我需要确保用户#1 永远不会获得属于用户#2 的客户的信息。

换句话说：如果用户#1 访问http://myapp.com/cars，他将看到属于用户#1 的客户的汽车列表

如果 id=131 的汽车属于用户#1 的客户，则只有用户#1 必须能够访问此信息 ( http://myapp.com/car/1 )。如果用户#2 在浏览器中插入相同的链接，他不必能够看到此信息。

有人建议我在用户和每个数据库表之间创建一个关系，以检查一条记录是否与 current_user 相关联。

你怎么看？最好的方法/解决方案是什么？

我在 POCO 类和我的数据库之间有一个 Linq-To-Sql 映射。我希望能够在我的类上添加属性，这些属性表示比简单的标量值稍微复杂的构造。

例如，我有一个自定义结构类型，它包含两个简单的标量值。我不想把它变成另一个表，然后添加一个 FK 作为属性。是否可以使用 Linq-to-Sql XML 映射文件映射此结构的属性？

例如，

我将如何指定Blah,Yada.A和Yada.B都作为表中的列保存Foo？

这甚至可以做到吗？

在我的 Rails 应用程序中，我有各种包含用户数据的数据库表。其中一些表有很多行（在某些情况下每个用户多达 500,000 行）并且经常被查询。每当我查询任何表的任何内容时，当前用户的 user_id 都在查询中的某个位置 - 如果表与用户有直接关系，或者通过连接，如果它们通过其他一些表相关，则可以直接使用。

我是否应该对 user_id 进行非规范化并将其包含在每个表中，以获得更快的性能？

这是一个例子：

• 地址属于用户，并且有一个user_id
• 信封属于用户，并且有一个 user_id
• AddressesEnvelopes 连接了地址和信封，因此它有信封_id 和地址_id——它没有用户id，但可以通过信封或地址（必须属于同一用户）到达它。

一个常见的昂贵查询是为特定用户选择所有 AddressesEnvelopes，我可以通过加入 Address 或 Envelope 来完成，即使我不需要这些表中的任何内容。或者我可以在此表中复制用户 ID。

这是一个不同的场景：

• 字母属于用户，并且有一个user_id
• Recepient 属于 Letter，并且有一个 letter_id
• RecepientOption 属于 Recepient，并且有一个recepient_id

在 Recepient 和 RecepientOption 中复制 user_id 是否有意义，即使我总是可以通过关联，通过 Letter 来获得它？

一些注意事项：

• 用户之间永远不会共享任何对象。相关对象的整个层次结构始终属于同一用户。
• 对象的用户所有者永远不会改变。
• 数据库性能很重要，因为它是一个数据密集型应用程序。有许多查询和许多表。

那么我应该在每个表中包含 user_id 以便在创建索引时使用它吗？或者那会是糟糕的设计？

当谈到对事务数据库中的数据进行非规范化以提高性能时，（至少）有三种不同的方法：

1. 通过存储过程推送更新，该存储过程更新规范化的事务数据和非规范化的报告/分析数据；

2. 在更新辅助表的事务表上实现触发器；这几乎是维护历史时所采取的路线；

3. 将处理推迟到夜间批处理，可能会在数据集市/仓库中执行 ETL。

出于这个问题的目的，我们假设选项 #3 不可行，因为域要求非规范化数据始终与规范化数据一致。我经常处理的分层聚合就是一个例子。

我已经相当多地使用了前两种方法，最近我一直倾向于基于触发器的方法，但我想知道是否有任何“陷阱”我还没有发现，并认为它值得问这个问题，所以我在未来做出长期决定时会有一些想法要记住。

因此，根据您的经验，对于维护实时非规范化数据的特定目的，这两种工具的优缺点是什么？在什么情况下你会选择其中一种，为什么？

（PS 请不要回答“触发器太复杂”或“所有更新应始终通过存储过程”之类的答案 - 使其适合问题的上下文。）

问这个我很惭愧，但最近出现了一种情况，我需要为三种不同类型的相互关联的银行实体创建一个表。让我解释。

想象一个 BANK 表，其中包含管理银行或经营农村分支机构的常规银行，或在该银行下运营的农村分支机构或不属于此层次结构但仅与农村分支机构进行交易的零售银行分行的详细信息。

以前，我决定为这些设置 4 个不同的表，具有 FK 约束（即管理银行、经营农村分行的银行、农村分行和零售银行分行各一个）。但是当我继续创建 TRANSACTION 表时，我感到很困惑，因为任何这些实体之间都可能发生交易（例如：农村分支机构与零售分支机构之间，农村分支机构之间等）。这意味着我不仅要记录银行实体的“源”和“目标”ID，还要保留一些数据来帮助应用程序逻辑确定要加入哪个表以进行查询。我觉得那是坏的。

此外，还有一个 USER 表，用户可以属于这些实体中的任何一个，这里也有 4 个不同的银行实体表是有问题的。我如何知道用户属于农村分行、零售分行还是管理银行？

因此，我创建了一个 BANK 表（主要是因为它们是相似的实体，因为它们可以相互交易）。我在表中添加了一个 PARENT 列，该列将保存父机构的 ID 值（我使用 FK 实现的关系）。因此，农村分行将在其父列中具有运营银行的 ID。零售分支机构没有父母，因此那里的值为 NULL 等等。

我现在看到的问题是BANK表中有PK/FK关系，一个循环引用。

我的问题是：这有多糟糕？什么是出路？

我的问题可能与之前在这里提出的问题相呼应： How to design a User Object Model using MS Roles & Membership，但我又问了一遍，因为还没有好的答案，而且我的问题是针对数据模型设计的反正：

所以无论如何，在我的应用程序中，有用户和组。一个用户可以属于许多组，当然一个组可以包含许多用户。现在的问题是，我们只知道几个基本组：用户、访客和管理员。将来，可能会有 can-do-X、can-do-Y 组，并且可能会更多或不超过管理员、用户和访客。所以我很想采取简单的方法。以下是我对这些方法的看法：

如果我打算有一个简单的用户表和一个角色表以及另一个模拟多对多关系的表，它似乎有点过度设计。如果我理解正确，这将被视为规范化方法。相反，如果我在 User 表中放入以下列，如 IsAdmin、IsGuest、CanDoX、CanDoY 等，那么这将是非规范化的。

我希望在复杂性和灵活性、时间和空间等之间取得平衡。请提出建议。

我的网络应用程序处理民意调查（调查）。现在我有 2 个表作为数据库模式的一部分。

问题在于，在一些民意调查中，我有很多回复（> 1000）。人们可以查看投票结果，它将显示有多少用户投票赞成、反对或可能，以及有多少匿名用户投票赞成、反对或可能。这样做的问题是，每当用户查看投票结果时，它必须遍历所有响应并计算响应的总数、每个选择的响应数、用户做出的每个选择的响应数，以及#tracker_id（匿名用户）做出的每个选择的响应并计算百分比并将其显示在条形图中。这使得页面加载非常缓慢。我正在考虑对数据库进行非规范化以提高性能，这样我们就有了这样的东西

也就是说，对于 中的值total_responses，10 是总数，3 是选择的响应数yes，3 是选择的响应数no，4 是选择的响应数maybe。相同的格式适用于user_responses和anon_responses字段。如果我能就这种方法得到一些意见，将不胜感激！谢谢你的时间。

编辑：我正在使用 MySQL

我听到了很多关于非规范化的信息，这些非规范化是为了提高某些应用程序的性能。但我从未尝试做任何相关的事情。

所以，我只是好奇，规范化数据库中的哪些地方会使性能变差，或者换句话说，什么是非规范化原则？

如果我需要提高性能，我该如何使用这种技术？