sql - 处理 "hypernormalized"数据

Question

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

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

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

我不确定的是我是否应该以这种格式保留数据，或者例如使用自引用关系将 Master/Department/Class/Subclass 合并到一个“Categories”表中，并将其链接到一个产品块(产品块应保持独立，因为它不是“类别”本身，而是给定类别的一组相关产品)。目前，产品块表引用子类表，因此如果我将它们合并在一起，这将更改为“category_id”。

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

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

Answer 1

我更喜欢“超规范化”方法而不是非规范化数据模型。您提到的自引用表可能会减少表的数量并在某些方面简化生活，但通常这种类型的关系可能很难处理。分层查询变得很痛苦，就像将对象模型映射到这个一样(如果你决定走那条路)。

几个额外的连接不会有什么坏处，并且会使应用程序更易于维护。除非由于连接数量过多而导致性能下降，否则我会选择保留原样。如果这些级别的表中的任何一个需要添加额外的功能，作为额外的好处，您将不会遇到问题，因为您将它们全部合并到自引用表中。