问题标签 [denormalization]

我有这个：

我想对 User.serials.episodes 做一些操作，但我知道这意味着各种巧妙的技巧。理论上，我可以将所有剧集数据放入串行（非规范化），然后在需要时进行 group_by 站点。

如果我有很多剧集需要查询，这会是个坏主意吗？

谢谢

我正在设计一个数据库，我想规范化数据库。在一个查询中，我将加入大约 30-40 个表。如果它变得非常流行，这会损害网站的性能吗？这将是主要的查询，它会在 50% 的时间里被调用。我将加入关于两个表的其他查询。

我现在可以选择规范化或不规范化，但如果将来规范化成为问题，我可能不得不重写 40​​% 的软件，这可能需要很长时间。在这种情况下，标准化真的会受到伤害吗？我现在应该在有时间的时候去规范化吗？

假设我有一个带有 2 个二级索引的“消息”表：

• “收件人 ID”
• “发件人ID”

我想按“recipient_id”对“消息”表进行分片。通过这种方式检索发送给某个收件人的所有消息，我只需要查询一个分片。

但同时，我希望能够进行查询，询问某个发件人发送的所有消息。现在我不想将该查询发送到“消息”表的每个分片。一种方法是复制数据并有一个由“sender_id”分片的“message_by_sender”表。

这种方法的问题在于，每次发送消息时，我都需要将消息插入“message”和“message_by_sender”表中。

但是如果在插入“message”之后插入“message_by_sender”失败了怎么办？在这种情况下，消息存在于“message”中，但不存在于“message_by_sender”中。

我如何确保如果一条消息存在于“消息”中，那么它也存在于“message_by_sender”中而不诉诸两阶段提交？

对于任何对其数据库进行分片的人来说，这一定是一个非常普遍的问题。你怎么处理它？

阅读此问题后，我了解到非规范化不是简单的解决方案。这个案子怎么办？

我有新闻文章，其中包含网站文章将发布到的列表。后者可以通过表和多对多关系（我认为通过交叉表）以标准化方式表示。但简单的解决方案是只为站点文章将被发布到（publish_to_site_1、publish_to_site_2 等）添加一堆布尔值。假设站点是：

1. 数量少
2. 不会随着时间而改变
3. 本身没有字段，除了名称

这仍然是一个可怕的想法吗？多对多的关系似乎有些麻烦，但我以前在这种情况下做过（而且看起来很麻烦）。

注意：我在 Rails 中这样做，它并不那么痛苦。另一方面，元编程使这样的事情变得微不足道

在 Oracle 中，表簇是一组共享公共列并将相关数据存储在相同块中的表。当表被聚集在一起时，一个数据块可以包含来自多个表的行。例如，一个块可以存储来自employees 和departments 表的行，而不是只存储一个表中的行：

http://download.oracle.com/docs/cd/E11882_01/server.112/e10713/tablecls.htm#i25478

这可以在 SQLServer 中完成吗？

如果我有需要存储在数据库中的大型文章，每个与许多表相关联的 NoSQL 选项会有所帮助吗？我应该将 1000 个字符文章复制到多个“桶”上，每次与桶相关时都复制它们，还是应该使用具有大量 Memcache 的规范化 MySQL 数据库？

根据我在下面提供的信息，您能否就将单独的表格非规范化为一个包含不同类型合同的表格是否是一个好主意给我您的意见？..什么是赞成/反对的？..有没有人尝试过这个之前？.. 银行系统使用 CIF（客户信息文件）[master]，其中客户可能有不同类型的账户、CD、抵押贷款等，并使用交易代码 [types]，但他们是否将它们存储在一个表中？

我有单独的表用于贷款、采购和销售交易。这些表中的每一个的行以下列方式连接到其对应的客户：

由于这些表中有很多共同的属性，它们都围绕着相同的商品：当铺、购买和出售，我通过将它们合并到一个名为“Contracts”的表中进行实验，并添加了以下列：

设想：

客户最初典当商品，支付了几次利息，然后决定将商品出售给典当行，典当行然后将商品放入库存并最终将其出售给另一位客户。

我设计了一个通用表，例如：

在贷款合同中，它持有典当本金，在购买中持有购买价格，在销售中持有销售价格。

这个设计是个好主意还是我应该把它们分开？

场景：

大系统（约 200 个表）。
60,000 名用户。
复杂的报告需要我为每个报告执行多个查询，甚至那些将是复杂的查询，内部查询遍布整个地方 + 一些 PHP 处理。

该方法：

我见过一种方法，但我不确定：
有一个集中的、非规范化的表，用于记录系统中任何可报告的活动。该表将主要保存外键，因此她应该相当紧凑和快速。
因此，例如（我的系统是一个虚拟学习管理系统），一个用户注册课程，表中存储了用户id、日期、课程id、组织id、活动类型（注册）。
当然，我还将这些数据存储在实际应用程序使用的规范化数据库中。

优点：用于处理数据和快速检索的简单、可维护的查询和代码。
缺点：非规范化表存在与真实数据库不同步的危险。

这种方法是否值得考虑，或者（最好根据经验）总计 $#%#%t？

我有一个 wiki 系统，其中有一个中央表 Article，它在自己的表中有许多修订。每个修订都包含 created_at 时间和日期列。

我想更新文章以包含来自最新修订名称字段的非规范化字段 sort_name。

我可以发出什么 SQL 命令来用其最新修订的名称字段填写每篇文章的 sort_name 字段？

对于它的价值，我在 PostgreSQL 上。

背景：：：：

我正在使用适用于 Java 的谷歌应用引擎 (GAE)。我正在努力设计一个能够发挥大表优势和劣势的数据模型，这是之前的两个相关帖子：

• 数据库设计——谷歌应用引擎
• 约会和行项目

我暂时决定使用一个完全规范化的主干，并将非规范化的属性添加到实体中，以便大多数客户端请求只需一个查询即可得到服务。

我认为完全标准化的主干将：

• 如果我在非规范化中编码错误，请帮助维护数据完整性
• 从客户端的角度来看，在一个操作中启用写入
• 允许对数据进行任何类型的意外查询（只要愿意等待）

而非规范化数据将：

• 使大多数客户端请求能够非常快速地得到服务

基本的非规范化技术:::

我观看了一段描述称为“扇出”技术的应用引擎视频。这个想法是快速写入规范化数据，然后使用任务队列在后台完成非规范化，而无需客户端等待。我已在此处包含视频以供参考，但它长达一个小时，无需观看即可理解这个问题： http ://code.google.com/events/io/2010/sessions/high-throughput -data-pipelines-appengine.html

如果我使用这种“扇出”技术，每次客户端修改一些数据时，应用程序都会在一次快速写入中更新规范化模型，然后将非规范化指令发送到任务队列，这样客户端就不必等待他们也要完成。

问题：：：

使用任务队列来更新数据的非规范化版本的问题在于，客户端可以在任务队列完成数据的非规范化之前对他们刚刚修改的数据发出读取请求。这将为客户端提供与他们最近的请求不一致的陈旧数据，从而使客户端感到困惑并使应用程序出现错误。

作为补救措施，我建议通过 URLFetch 异步调用应用程序中的其他 URL 来并行展开非规范化操作：http://code.google.com/appengine/docs/java/urlfetch/ 应用程序将等到所有在响应客户端请求之前，异步调用已完成。

例如，如果我有一个“约会”实体和一个“客户”实体。每个约会将包括为其安排的客户信息的非规范化副本。如果客户更改了他们的名字，应用程序将进行 30 次异步调用；为每个受影响的预约资源提供一个，以便更改每个客户名字的副本。

理论上，这一切都可以并行完成。所有这些信息可以在大约向数据存储进行 1 或 2 次写入所需的时间内更新。非规范化完成后可以及时响应客户端，消除客户端暴露于不一致数据的可能性。

我看到的最大潜在问题是应用程序在任何时候都不能有超过 10 个异步请求调用（在此处记录）：http ://code.google.com/appengine/docs/java/urlfetch/overview .html）。

提出的非规范化技术（递归异步扇出）:::

我建议的补救措施是将非规范化指令发送到另一个资源，该资源递归地将指令拆分为大小相等的较小块，以较小的块作为参数调用自身，直到每个块中的指令数量小到可以直接执行。例如，如果有 30 个相关约会的客户更改了他们名字的拼写。我会调用非规范化资源并提供更新所有 30 个约会的说明。然后，它将这些指令分成 10 组，每组 3 条指令，并使用每组 3 条指令向其自己的 URL 发出 10 个异步请求。一旦指令集小于 10，资源就会根据每条指令直接发出异步请求。

我对这种方法的担忧是：

• 它可以被解释为试图规避应用程序引擎的规则，这会导致问题。（它甚至不允许 URL 调用自身，所以我实际上必须有两个 URL 资源来处理相互调用的递归）
• 它很复杂，有多个潜在故障点。

我非常感谢您对这种方法的一些意见。