问题标签 [normalizing]

我正在做一个需要解析日志文件的项目。我正在寻找一种快速算法，可以接收这样的组消息：

P1 处的温度为 35F。

P1 处的温度为 40F。

P3 处的温度为 35F。

记录仪停止。

记录仪启动。

P1 处的温度为 40F。

并以 printf() 的形式输出一些东西：

该算法需要足够通用以识别消息组中的几乎所有数据负载。

我尝试搜索这种技术，但我什至不知道要搜索的正确术语。

我需要存储用户的联系信息。我想在页面上将这些数据显示为hCard并以vCard的形式下载。我还希望能够通过电话号码、电子邮件等搜索数据库。

您认为存储这些数据的最佳方式是什么？由于用户可能有多个地址，等等完整的规范化将是一团糟。我正在考虑使用 XML，但我不熟悉查询 XML 数据库字段。我还能通过联系信息搜索用户吗？

我正在使用 SQL Server 2005，如果这很重要的话。

一位前同事坚持认为，具有更多表且每列更少的数据库比具有更少表且每列更多的数据库要好。例如，不是包含名称、地址、城市、州、邮编等列的客户表，而是名称表、地址表、城市表等。

他认为这种设计更加高效和灵活。也许它更灵活，但我没有资格评论它的效率。即使它更有效，我认为这些收益可能会被增加的复杂性所抵消。

那么，与具有更多列的更少表相比，具有更少列的更多表有什么显着的好处吗？

好的，所以我现在正在为“Box Items”制作一张表格。

现在，一个盒子项目，取决于它的用途/项目的状态，最终可能与“运输”盒子或“退货”盒子相关。

Box Item 可能有缺陷：如果是，则会在 Box Item 的行中设置一个标志 (IsDefective)，并且 Box Item 将被放入“Returns”框中（与其他物品一起退回给该供应商）。否则，Box Item 最终将被放入“Shipping”盒子（与其他要运送的物品一起）。（请注意，运输和退货箱有自己的表格：所有箱子都没有一个公用表格......尽管如果可能的话，我应该考虑这样做作为第三种可能性？）

也许我今天只是想不清楚，但我开始质疑在这种情况下应该怎么做。

我的直觉告诉我，我应该为每个可能的关系设置一个单独的字段，即使在任何给定时间只能发生其中一个关系，这将使 Box Items 的架构看起来像：

BoxItemID 描述 IsDefective ShippingBoxID ReturnBoxID 等...

这将使关系变得清晰，但似乎很浪费（因为任何时候都只会使用其中一个关系）。所以我想我可以只有一个 BoxID 字段，并根据 IsDefective 字段确定它指的是哪个 BoxID（运输或退货箱 ID）：

BoxItemID 描述 IsDefective BoxID 等...

这似乎不那么浪费，但不适合我。关系不明显。

所以，我把它交给你，Stackoverflow 的数据库专家。在这个情况下，你会怎么做？

编辑：谢谢大家的意见！它给了我很多思考。一方面，下次我开始这样的项目时，我将使用 ORM。=）两个，因为我现在不在，我会咬四个字节并使用两个字段。

再次感谢大家！

我需要一个可以在单个维度内存储非重叠范围的数据结构。不需要完全覆盖整个尺寸范围。

一个例子是会议室调度程序。维度是时间。没有两个时间表可以重叠。会议室并不总是安排好的。换句话说，对于给定的时间，最多可以有一个时间表。

一个快速的解决方案是使用一个范围来存储开始和结束时间。

这是非规范化的，需要容器强制不重叠。对于两个相邻的范围，前一个结束将与下一个开始冗余。

另一种方案可能涉及为每个范围存储一个边界值。但是对于连续的范围序列，边界值总是比范围多一个。为了解决这个问题，序列可以表示为交替的边界值和范围：

B = 边界值，r = 范围

溴化溴

数据结构可能如下所示：

从本质上讲，它是一个具有交替类型的双向链表。

最终，我使用的任何数据结构都将在内存（应用程序代码）和关系数据库中表示。

我很好奇存在哪些学术或行业尝试过的解决方案。

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

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

我有一个 PHP Web 应用程序，它使用 MySQL 数据库进行对象标记，其中我使用了接受的标记结构作为这个 SO question的答案。

我想实现一个标签层次结构，其中每个标签都可以有一个唯一的父标签。然后，对父标签 T 的搜索将匹配 T 的所有后代（即 T、父标签为 T（T 的子代）、T 的孙子代等）。

最简单的方法似乎是在标签表中添加一个 ParentID 字段，该字段包含标签的父标签的 ID，或者如果标签没有父标签，则包含一些幻数。然而，搜索后代需要对数据库进行重复的完整搜索以找到每个“世代”中的标签，我想避免这种情况。

一种（可能）更快但标准化程度较低的方法是拥有一个包含每个标签的所有子代，甚至每个标签的所有后代的表。然而，这会带来数据库中数据不一致的风险（例如，标签是多个父级的子级）。

有没有一种好方法可以让查询快速找到后代，同时保持数据尽可能规范化？

我有一个大型访问数据库，需要将其规范化为五个表和一个查找表。我了解规范化背后的理论，并且已经勾勒出表格的外观，但我不知道如何转换表格以使数据库标准化。表格分析器不提供我想要的细分。

我必须维护一个未正确规范化的旧数据库。例如，有一个项目表已经增长（或者可能像蘑菇一样）有 5 个或更多不同的日期列，用于项目从订购到交付日期的不同里程碑。还有几个表格，每个表格都有街道地址、邮件地址或网络链接的列。

我想规范化结构，为地址、预定日期等创建表格，以及允许 1:N 关系的必要表格（每个客户的地址、每个项目的截止日期等）。

现在我完全不确定如何处理对明细表中数据的更改。例如，考虑更改客户送货地址。更改地址表中的数据是不可能的，因为有多个记录（可能在多个表中）可以引用该记录。如果没有其他行与旧记录有外键关系，则添加新地址记录可能会使旧记录成为孤立记录。

我考虑过以下方法来处理这个问题：

• 添加新的明细记录，并在主表的更新触发器中检查是否必须删除旧的明细记录。这将需要所有与详细表有关系的表的知识，在所有表中或在存储过程中。我不喜欢这种失去分离的感觉。它还将在活动事务中涉及更多表。

• 让触发器尝试删除旧的详细记录，并捕获任何错误。这只是感觉不对。

• 与孤立记录一起生活，并定期进行维护任务以清理所有详细信息表。

在链接到多个主表的明细表中处理数据更改的首选方法是什么？阅读此内容的任何提示？

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

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

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

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

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

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