问题标签 [normalization]

非规范化企业应用程序数据库的优点/缺点是什么，因为它会使编写报告更容易？

Pro - 在 SSRS 中设计报告可能会“更容易”，因为不需要连接。

由于数据重复和同步，开发/维护应用程序以处理非规范化数据将变得更加困难。

其他的？

我对 PHP MySQL 还比较陌生，并要求自己学习“动手”方法。幸运的是，我目前有一个（非常）大的数据库，所有数据库都与硬币数据相关，并有一张表可供使用。它目前具有以下列（每一行代表一个项目 [coin]）：

新表的分组比较明显：

时期：

面额：

类型：

所有其余的，在硬币表下：

所以我希望将表格规范化为指定的表格。我知道我正在查看 JOIN，但我想知道最好的方法。我是否首先使用每个数据组（Denom、Period、Type）创建一个新表，然后使用 JOIN 语句插入数据？或者有没有办法使用 JOIN 语句“即时”创建新表。我在这里打开了一本很棒的书，并且很好地遵循了有关 MySQL 的部分并浏览了该站点，但无法找出“正确”的方法来做到这一点。

我在这里要求一些知识渊博的建议的原因是我有点不确定如何维护“关系”和键等。即，如果我创建一个名为“Denom”的表并用所有不同的项目填充它当前表数据并让它创建一个唯一的主键，然后我如何将 Denom 表中对这个新主键的引用插入主 Coin 表（在新项目 DenomID 下），以便它们匹配？

我基本上需要将此表拆分为 4 个单独的表。我已经使用 Access 2007 的表分析器向导进行了尝试，对于像我这样的 n00b 来说，它看起来很有希望，但是数据太多，它实际上崩溃了。反复。可能是最好的，但现在我需要知道一些最佳实践，以及如何将其付诸实践。任何建议/帮助/相关链接将不胜感激。

我有一个需要进行一些更改的现有数据库。我需要决定是更改表以记录额外数据还是使用已经记录该数据的现有表进行单独测试并将其链接到具有新表的另一个表。

现存的：

选项1：

选项 2：

基本上它的工作方式是在测试序列开始时进行一次检查压力体积的测试。现在他们想每五分钟记录一次它和其他电气数据。他们仍将执行初始压力容量测试。

所以我有一个用户表；存储用户名、电子邮件等内容。然后我有一个 user_settings 表。我将其组织为键/值组合，而不是像 timestamp_logged_in、profile_views 等标准列。例如，这些列是：

user_settings_ID user_ID 名称值

示例记录为：82 2 'timestamp_logged_in' '2009-10-10 02:23:53'

这使设置更具渗透性。我不需要存在列来存储新的用户设置类型。我担心这样做（这会将每个值存储为字符串，并且我会将其转换为中间件中的适当类型）会使排序变得困难。因此，例如，如果我想按上次登录的顺序获取用户列表，排序将需要一个 sql 调用，例如：

SELECT user_ID FROM user.settings WHERE status='open' AND name='timestamp_logged_in' ORDER BY name

但是，这会将找到的记录排序为字符串。有没有办法确保排序算法 mysql 是基于某个值类型实现的（例如，强制它将排序列视为字符串、整数、日期时间、时间戳等）？

任何想法都会非常感激。谢谢。奥利弗·纳萨尔

我正在使用 3NF 在 grails 中实现多对多映射，而不使用 hasMany 或 belongsTo 属性。

摘自这篇文章，它展示并解释了很多关于它的优势。

文章：http ://burtbeckwith.com/blog/?p=169

演示说明：http ://burtbeckwith.com/blog/files/169/gorm%20grails%20meetup%20presentation.pdf

我正在尝试为问题制作一个标签系统，有点像这样（stackoverflow :)）

我可以保存问题和标签，然后保存与它们的关联，但现在我希望能够搜索并提供带有标签的完整问题，

我有 3 个域类 - Question、Tag 和 QuestionTag

标记类

QuestionTag 类

这些产生 3 个表格，以 3 个标准化形式

保存作品、问题和标签数量。

Q.1如何加载“问题”及其“标签”集？如果有 5 个标签与问题相关联。

现在我安装了“searchable”插件，我将“static searchable=true”应用于所有三个类。但是当我将该属性添加到 QuestionTag 类时出现编译错误，这与缺少“hasMany”有关，

Q.2如果我添加“hasMany”，它会在后台生成另一个表，但我已经定义了自己的表。还是它会引用我制作的 QuestionTag 表？

Q.3使用 3NF 无论如何我都可以搜索标签和问题全文，然后返回与匹配标签或文本的搜索关键字相关的问题。

我正在与某人讨论下表，该表用于链接特定于客户的项目：

这是有争议的设计。所有三个字段都引用其他表。两个 Item 字段引用同一个其他表。这些不是真正的字段名称，因此不必费心讨论命名约定（然而，“1”和“2”实际上是字段名称的一部分）。我认为这种设计在违反 1NF 的基础上是不好的，而另一个人则认为即使这看起来令人反感，但对于我们的特定用例来说，所有其他选择都更糟糕。

笔记：

• 绝大多数情况只需要将两个项目相互链接；
• 但是允许 N:1 组；在这种情况下，相同的 Item1 在具有不同 Item2 值的多行上重复；
• 在极少数情况下，某些 Item2 值（在现有 Item1-Item2 链接中）本身链接到其他 Item，在这些情况下，这些值出现在 Item1 列中，而另一个链接值出现在 Item2 列中; 所有链接的项目都对应一个组，并且必须这样检索。

我的主张：

• 这违反了1NF：Item1和Item2是同一张表的外键，因此构成一个重复组（对方对重复组的定义不同意）；
• 对于 Item 的搜索，这意味着需要两个索引而不是一个，例如在使用 GroupID 字段的表中；
• 这使得在此表中查找特定项目的查询更加复杂，因为限制子句必须同时检查 Item1 和 Item2 字段。
• 对于出现项目链接链的情况的检索将更加复杂。

对方声称：

• 最可行的替代方案是具有单个 Item 字段和附加 GroupID 字段的表；
• 更简单、更常见的两项链接案例现在变得更加复杂；
• 获取 GroupID 插槽时可能存在并发问题，需要对其进行管理
• 管理 GroupID 并发问题可能需要在具有唯一性约束的字段中使用 GroupID 的第二个表
• 您现在必须至少在某些时候执行连接，尤其是在使用 ORM 的情况下。与在当前设计中使用单个表相比，连接效率较低。

我想听听对此的一些看法。我已经阅读了关于数据库设计的其他帖子，尤其是 1NF，但它们并没有像我希望的那样专门处理我上面的案例。根据网上的大量研究，我还了解到，像 1NF 这样的所谓标准可以由不同的人以多种不同的方式定义。我试图尽可能清楚地说明这两种论点，而不是偏袒其中一种。

编辑1：

• Item1 和 Item2 是（金融）交易
• “1”和“2”实际上是字段名称的一部分

您将下面的示例规范化到什么程度，以及该示例到底符合哪个规范化级别？

需要注意的是，每条记录只能有 0 或 1 个家庭、移动、工作或传真号码记录。每个电话号码的功能完全取决于我的主键。根据我对数据库规范化的了解，我认为这符合 5NF，但不符合 6NF。

由于电话号码定义是一成不变的（没有新的电话号码类型，没有多个 home_phone 条目等），我是否有任何理由要将电话号码拆分为由 (contact_info_id, phone_number, type) 跟踪的单独关系?

有谁知道任何简单的方法来英语化一个字符串？目前，在我们的系统中，我们正在对“无效”字符进行替换，如下所示：

这里的问题是，当我们在其他国家/地区（土耳其、俄罗斯、匈牙利……）开展业务时，我们发现有很多角色在此过程中无法转换。

有没有人知道任何类型的解决方案可以让我们不依赖于“无效”字符表？

此外，如果有帮助，我们正在使用 C# 进行编码。:)

谢谢！

编辑：

作为对一些评论的回应，我们的系统确实支持完整的 unicode 字符集……但是，我们集成到的其他系统（例如卡处理器）不支持。:(

在这里输出是：

这看起来是正确的，几乎所有的 Web 服务器都会将以下两个处理为相同的请求：

解决此行为的最佳方法是有任何 API 来执行此操作，还是应手动创建一个新的 URI 并删除路径中的所有 ////？

我有 2 个表。一个是 OrderMaster，第二个是 OrderDetails。两者都通过 OrderId 连接

订单表字段：OrderId(Primary Key),Total,OrderDate

OrderDetail 字段：OrderDetailId,ItemId,SupplierId,Amount,OrderId (ForiegnKey)

一个订单可以有多个来自不同供应商的订单详细记录

现在我想获得仅具有特定供应商 ID 值（例如：4）和计数（不同供应商 ID）=2 的订单。所有具有此供应商 ID 的订单不应包含在结果集中，因为其中一些可能有其他供应商也。预期输出是 OrderId, Sum*Amount 对于那些属于特定供应商的记录（订单中只有这个供应商）

编辑：我认为 Count(supplierId)=1 应该是查询的一部分。