问题标签 [denormalization]

我有一个规范化订单数据的大型数据库，查询报告变得非常缓慢。我在报表中使用的许多查询连接了五六个表，并且必须检查数万或数十万行。

有很多查询，并且大多数都已尽可能优化以减少服务器负载并提高速度。我认为是时候开始以非规范化格式保存数据副本了。

关于方法的任何想法？我应该从几个最糟糕的查询开始，然后从那里开始吗？

我正在对数据库进行一些研究，并且正在研究关系数据库的一些限制。

我知道大表的连接非常昂贵，但我不完全确定为什么。DBMS执行join操作需要做什么，瓶颈在哪里？
非规范化如何帮助克服这一开销？其他优化技术（例如索引）如何提供帮助？

欢迎亲身体验！如果您要发布资源链接，请避免使用 Wikipedia。我知道在哪里可以找到那个了。

与此相关，我想知道 BigTable 和 SimpleDB 等云服务数据库使用的非规范化方法。看到这个问题。

我目前正在构建一个新的应用程序，具有很高的读写比率。在我现在的雇主中，出于性能原因，我们的表格上有很多非规范化数据。拥有完全 3NF 表然后使用索引视图进行所有非规范化是更好的做法吗？我应该对表或视图运行查询吗？

我感兴趣的一些事情的一个例子是列子表的聚合（例如，将用户帖子计数存储在某处）。

我正在寻找一种策略，以阻止重复分支表的问题。例如，作为一个虚构的用例，假设我有一个包含用户名、登录名、密码和其他元数据的用户表。在这个特定的场景中，假设用户被限制为每个特定的 IP 子集登录。因此，我们有一个 1:M 的关系。每次出现诸如以下的用例时，您的正常工作流程包括拥有一个“用户”表和一个诸如“user_ips”之类的表，在这种情况下，您将拥有诸如 pk(ip_id)、fk( user_id) 和 user_ips 端的 IP。

对于类似的情况，你们通常会按照上面的方式扇出吗？这里有机会有效地去规范化吗？也许以某种 CSV 分隔的方式将 IP 存储在 BLOB 列中？你们今天正在部署哪些策略？

规范化导致许多基本和理想的特征，包括审美愉悦。此外，它在理论上也是“正确的”。在这种情况下，非规范化被用作一种折衷方案，一种实现性能的校正。除了性能之外，还有什么原因可以使数据库非规范化？

我与我不拥有且无法更改的数据库建立了 ODBC 连接。我要做的是使相关记录合并为一条记录。关系是一对多。

我有一个学生管理系统，想要导出一个提供自动标注服务（由呼叫收费）的呼叫列表。如果有多个学生住在那里，我希望能够只给一个房子打电话一次。

所需的调出文件结构：

与现有数据相比：

有什么建议么？

在试图弄清楚如何在此处使用单个 sql 语句标记博客文章时，我想到了以下想法：使用按 id 引用标签的关系表 tag2post 如下所示：

为什么不只使用以下模型，您可以在其中索引标签本身，如下所示？认为标签永远不会重命名，而是添加和删除，这可能是有道理的，对吧？你怎么看？

PS：我保留一个id，我是为了轻松显示添加的最后n 个标签...

我正在为保险业开发一个 Web API，并试图为保险报价制定合适的数据结构。

数据库已经包含一个“评级”表，基本上是：

[编辑] 每种类型的商品通常有 3 - 4 个投保范围 [/编辑]

goods_types 列表很少更改，大多数保险查询将涉及价值低于 100 美元的商品。因此，我正在考虑使用以下格式的表格进行反规范化（对于从 $0.00 到 $100.00 的所有值）：

对这些数据进行非规范化应该很容易维护，因为费率通常最多每月更新一次。所有价值大于 100 美元的请求将始终在主表中查找并计算。

我的问题是：
1. 我最好将总和值存储为 DECIMAL(9,2) 还是存储在 BIGINT 中的美分值？
2. 这种反规范化方法涉及在可能的 20 个表中存储 10,001 个值（0.00 美元到 100.00 美元，增量为 0.01 美元）。这可能比查找 percent_premium 并执行计算更有效吗？- 还是我应该坚持使用主表并进行计算？

我的雇主是一家小型办公用品公司，正在更换供应商，我正在查看他们的电子内容以提出一个强大的数据库架构；我们之前的模式几乎是完全不加思索地拼凑在一起的，而且它几乎导致了一个无法忍受的数据模型，其中包含损坏的、不一致的信息。

新供应商的数据比旧供应商的数据要好得多，但他们的数据就是我所说的超标准化。例如，他们的产品类别结构有5个层次：Master Department、Department、Class、Subclass、Product Block。此外，产品块内容具有产品的长描述、搜索词和图像名称（想法是产品块包含产品和所有变体 - 例如，特定的笔可能采用黑色、蓝色或红色墨水；所有这些items 本质上是相同的东西，因此它们适用于单个产品块）。在我得到的数据中，这表示为产品表（我说“表”，但它是一个包含数据的平面文件），它引用了产品块的唯一 ID。

我正在尝试提出一个强大的模式来容纳我提供的数据，因为我需要相对较快地加载它，而且他们给我的数据似乎与他们的数据类型不匹配在他们的示例网站 ( http://www.iteminfo.com )上提供演示。无论如何，我不打算重用他们的演示结构，所以这是一个有争议的问题，但我正在浏览该网站以了解如何构建事物的一些想法。

我不确定是否应该以这种格式保存数据，或者例如使用自引用关系将主/部门/类/子类合并到一个“类别”表中，并将其链接到产品块（产品块应该分开，因为它不是一个“类别”，而是给定类别的一组相关产品）。目前，产品块表引用子类表，因此如果我将它们合并在一起，这将更改为“category_id”。

我可能会创建一个电子商务店面，利用 Ruby on Rails 上的这些数据（或者这是我的计划，无论如何），所以我试图避免以后被卡住或拥有一个臃肿的应用程序 - 也许我我想太多了，但我宁愿安全也不愿后悔；我们之前的数据一团糟，由于数据不一致和不准确，公司损失了数万美元的销售额。此外，我将通过确保我的数据库是健壮的并强制执行约束来稍微打破 Rails 约定（我也计划在应用程序级别这样做），所以这也是我需要考虑的事情。

你会如何处理这样的情况？请记住，我已经将数据加载到模拟表结构的平面文件中（我有文档说明哪些列是哪些列以及设置了哪些引用）；我正在尝试决定是否应该让它们像目前一样正常化，或者我是否应该寻求整合；我需要知道每种方法将如何影响我使用 Rails 对网站进行编程的方式，因为如果我合并，一个表中基本上会有 4 个“级别”的类别，但这似乎比单独的表更易于管理每个级别，因为除了子类（直接链接到产品块）他们不做除了显示它们下的下一级类别之外的任何内容。我总是对处理这样的数据的“最佳”方式感到茫然——我知道“规范化直到它受伤，然后非规范化直到它起作用”的说法，但直到现在我才真正需要实施它。

我有一个带有一些 DataTables 的 DataSet，这些 DataTables 与 DataRelations（经典订单 Header/Detail 对）链接在一起。有没有一种简单的方法可以将整个批次非规范化为具有相关表的所有列的单个 DataTable？

表名和列在编译时是未知的，可能有两个以上的表/关系。