处理"超标准化"数据

我的雇主,一家小型办公用品公司,正在转换供应商,我正在查看他们的电子内容,以提出一个强大的数据库架构; 我们以前的模式几乎没有任何想法就被抛在了一起,而且它几乎导致了一个无法忍受的数据模型,其中包含损坏的,不一致的信息.

新供应商的数据比旧供应商的数据要好得多,但他们的数据就是我称之为超标准化的数据.例如,他们的产品类别结构有5个级别:Master Department,Department,Class,Subclass,Product Block.此外,产品块内容具有产品的长描述,搜索术语和图像名称(这个想法是产品块包含产品和所有变体 - 例如特定笔可能有黑色,蓝色或红色墨水;所有这些项目基本上是相同的,所以它们适用于单个产品块).在我给出的数据中,这表示为产品表(我说"表",但它是带有数据的平面文件),其中引用了产品块的唯一ID.

我试图提出一个强大的模式来容纳我提供的数据,因为我需要相对较快地加载它,他们给我的数据似乎与他们的数据类型不匹配在他们的样本网站(http://www.iteminfo.com)上提供演示.无论如何,我不打算重复使用它们的表示结构,所以这是一个没有实际意义的点,但我正在浏览网站以获得有关如何构建事物的一些想法.

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

我可能会创建一个电子商务店面,利用Ruby on Rails中的这些数据(或者说这是我的计划,无论如何)所以我试图避免以后遇到障碍或者有一个膨胀的应用程序 - 也许我我给了它太多的想法,但我宁愿安全而不是抱歉; 我们以前的数据真是一团糟,由于数据不一致和不准确,使公司损失了数万美元.此外,我将通过确保我的数据库是健壮的并强制执行约束(我计划在应用程序级别执行它)来稍微摆脱Rails约定,所以这也是我需要考虑的事情.

你会如何解决这样的情况？请记住,我已经将数据加载到模拟表结构的平面文件中(我有文档说明哪些列是哪些列以及设置了哪些引用); 我正在试图决定是否应该像现在这样将它们保持正常化,或者我是否应该寻求巩固; 我需要知道每个方法将如何影响我使用Rails对网站进行编程的方式,因为如果我进行整合,单个表中基本上会有4个"级别"的类别,但这似乎比单独的表更易于管理每个级别,因为除了Subclass(直接链接到产品块),他们不这样做除了显示下一级别的类别之外的任何东西.对于处理这样的数据的"最佳"方式我总是感到茫然 - 我知道"正常化直到它受到伤害,然后反正规化直到它起作用"这句话但是我从来没有真正实现过它.

我宁愿在非正规数据模型上使用"超标准化"方法.您提到的自引用表可能会减少表的数量并在某些方面简化生命,但通常这种类型的关系可能很难处理.分层查询变得很痛苦,将对象模型映射到此(如果您决定走这条路线)也是如此.

一些额外的连接不会受到伤害,并将使应用程序更易于维护.除非由于连接数量过多导致性能下降,否则我会选择保留原样.如果任何这些级别的表需要添加其他功能,那么您将不会遇到问题,因为您将它们全部合并到自引用表中.