标题没有太大意义，但我想不出更好的标题来解决这个问题。

我有以下表格

项目

• ID
• 姓名

顾客

• ID
• id_project
• 姓名

付款

• ID
• id_customer
• 日期
• 和

当用户进入系统时，他将有权访问某个项目。现在，我想列出该项目的所有付款，这应该很容易：

SELECT FROM payments where id_customer in (SELECT id from customers where id_project = 5)

我的问题是：如果以这种方式向支付表添加一列 id_project 不是更好，那么查询会更容易和更快。

我在数据库中有相当数量的数据。我有格式良好的表格和它们之间的良好关系，我的数据中有一些冗余。但是我应该在规范化方面走多远？过多的标准化是否存在性能缺陷？

我们有一个团队为软件开发人员设计表格和关系。在我们的组织中，他们对执行 3NF 规范化非常严格——老实说，鉴于我们组织的规模以及需求或我们的客户如何随时间变化，我同意这一点。只有一个方面我不清楚他们设计决策背后的原因：地址。

虽然这主要集中在美国的地址，但我认为这适用于任何这样做的国家。地址的每一部分在地址表中都有自己的列。例如，以这个粗糙的美国地址为例：

Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222

它会像这样在数据库中拆分：

• 街道号码：485
• 街道分数：1/2
• 街道预定向：N（北）
• 街道名称：史密斯
• 街道类型：ST（街道）
• 街道后向：西南（西南）
• 城市：芝加哥
• 州：IL（伊利诺伊州）
• 邮编：11111
• 邮政编码：2222
• 国家（假设为美国）
• 注意：简·多伊
• 邮政信箱： NULL
• 户型：APT（公寓）
• 户数：300B

还会有一些其他与农村路线和合同路线相关的专栏。此外，我们的特定应用程序中可能会包含一些国际地址。数据建模人员表示，他们将添加特定于国际地址的列，这将是正常的第 1 行、第 2 行字段。

起初我认为这太过分了。在网上反复搜索是指使用地址行 1、2、3 和可能的 4，然后拆分出城市、地区和邮政编码。我们的新应用程序确实有一个用例，这种粒度是有益的。我们必须验证用户没有创建重复的业务，检查地址是验证之一。我们可以让它与地址行 1 和 2 一起工作，但这会更困难。

至于我们的具体应用，我们需要为企业和个人存储多种地址（物理、邮寄、运输等）。我们可能需要生成可打印的套用信函，但目前尚未讨论该要求。

我们组织中的应用程序需要支持的其他一些东西：

• 审计（使用完整的历史表）
• 打印邮寄标签
• 生成打印表格
• 报告（针对国家和地区政府）

虽然我们的应用程序可能不会做所有其他应用程序正在做的所有事情，但将地址拆分为多个组件是我工作的企业标准。不管我们的应用程序是否会从中受益，我们都被迫这样做。

半相关的 StackOverflow 问题：关闭的好的地址解析器在哪里，但说明解析地址有多么困难。

为了让我更好地理解他们的设计决策，并把这个想法卖给我们的客户……

将街道地址拆分为单独的列解决了哪些问题？

任何实施过此类系统的人都会获得奖励积分，因为他们遇到了问题。

我想要一种一对多的关系，其中对于每个父母，一个或零个孩子被标记为“最喜欢的”。然而，并不是每个父母都会有孩子。（将家长视为本网站上的问题，将孩子视为答案，将最喜欢的视为已接受的答案。）例如，

TableA
    Id            INT PRIMARY KEY

TableB
    Id            INT PRIMARY KEY
    Parent        INT NOT NULL FOREIGN KEY REFERENCES TableA.Id

在我看来，我可以将以下列添加到 TableA：

    FavoriteChild INT NULL FOREIGN KEY REFERENCES TableB.Id

或 TableB 的以下列：

    IsFavorite    BIT NOT NULL

第一种方法的问题在于它引入了一个可为空的外键，据我所知，它不是规范化形式。第二种方法的问题是需要做更多的工作来确保最多只有一个孩子是最喜欢的。

我应该使用什么样的标准来确定使用哪种方法？或者，还有其他我没有考虑的方法吗？

我正在使用 SQL Server 2012。

我最近了解了规范化，并了解在实现新模式时它的重要性。

如何检查我的数据库是否符合 2NF 或 3NF？

手动审查是一个确定的选择，但我正在寻找一种自动化工具。

我不是在寻找点击式工具，更多的是强调可能的优化以使表格符合 3NF。我猜它可能会使用基于良好样本数据和/或列名语义分析的统计数据。

我有一个表设计方案，并且作为非 DBA 类型，希望对哪个更可扩展提出意见。

假设您被要求记录一个都市区的房屋信息，从一个小社区（200 所房屋）开始，但最终增长到 5000000 多所房屋。

您需要存储基本信息：ID#（我们可以用作唯一索引的唯一批次 #）、地址、城市、州、邮编。很好，简单的表会处理它。

但是每一年，你都会被要求记录所有房子的额外信息——每年都有哪些信息会发生变化。因此，例如，第一年，您需要记录所有者的姓氏和面积。第二年，你被要求保留姓氏，但丢弃平方英尺，而是开始收集业主的名字。

最后 - 每年额外列的数量都会改变。可能从 2 个额外的列开始，然后到明年的 6 个，然后回到 2 个。

因此，一种表格方法是尝试将自定义信息添加为房屋表格中的列，因此只有一张表格。

但是我有一种情况，有人为此将表格布置为：

“房屋表”列：ID、地址、城市、州、邮编 - 每所房屋一行

ID   Addr              City     State  Zip 
-------------------------------------------
1    10 Maple Street   Boston      MA  11203

2    144 South Street  Chelmsford  MA  11304

3    1 Main Avenue     Lowell      MA  11280

“自定义信息表”列：ID、名称、值 - 表格如下所示：

ID   Name             Value

1    Last Name        Smith

2    Last Name        Harrison

3    Last Name        Markey

1    Square Footage   1200

2    Square Footage   1930

3    Square Footage …

我正在与另一位数据库设计人员就规范化进行有趣的讨论。在这个例子中，我们有一个 GameTitles 表，每条记录都必须包含游戏发布的年份。他说 2NF 要求所有内容都必须规范化，因此，要符合要求，年份字段应拆分为一个 ReleaseYears 表，该表具有自己的主键，由 GameTitles 表引用。我说它应该保留为 GameTitles 表本身的一个字段。

我对此的论点是，一年只是一个非原始数值，本质上是静态的（即，2011 年将始终是 2011 年）。因此，它充当自己的标识符，不需要引用它，因为它就是它。这也引入了额外的维护，因为您现在必须向表中添加新的一年才能引用它。如果您使用大范围的年份预先填充该表，那么您会有额外的记录，这些记录可能根本没有对它们的引用。这也增加了数据库大小，因为您现在有一个额外的表、记录开销和年份本身的额外主键。如果您将年份作为 GameTitles 表中的一个字段，则可以消除所有这些额外的维护和开销。

对此有何想法？

编辑：打算在 StackOverflow 上发布这个。有人可以投票删除此内容或将其标记以引起注意吗？

我从小就受过教育——在那里我们学会了在应用程序的业务层之前设计数据库模式（或将 OOAD 用于其他一切）。我一直很擅长设计模式（恕我直言:) 并且规范化只是为了删除不必要的冗余，而不是影响速度的地方，即如果连接是性能下降，冗余就留在原地。但大多数情况并非如此。

随着一些 ORM 框架的出现，如 Ruby 的 ActiveRecord 或 ActiveJDBC（以及其他一些我不记得了，但我相信有很多）似乎他们更喜欢为每个表设置一个代理键，即使有些有主键，例如'email' - 彻底打破 2NF。好吧，我不太明白，但是当这些 ORM（或程序员）中的一些不承认 1-1 或 1-0|1（即 1 比 0 或 1）时，我（几乎）会感到紧张。他们规定，无论是否有大量nulls “今天的系统可以处理它”，最好将所有东西都放在一张大桌子上，这是我经常听到的评论。

我同意内存限制确实与规范化直接相关（还有其他好处:)但是在今天内存便宜和四核机器的时代，数据库规范化的概念是否只是留给文本？作为 DBA，您是否仍然练习标准化为 3NF（如果不是 BCNF :)？有关系吗？“脏模式”设计对生产系统有好处吗？如果它仍然相关，那么应该如何将其“用于”规范化。

（注意：我不是在谈论数据仓库的星形/雪花模式，它们具有冗余作为设计的一部分/需要，而是具有后端数据库（例如 StackExchange）的商业系统）

我正在阅读这篇 BBC 新闻文章和以下摘录，引起了我的注意。这听起来像是Always On Availability Groups或High Availability Mirroring，可能会自动包含安全性。

区块链是现代、高交易量应用程序的潜在可行数据库解决方案吗？

很容易看出它对个人医疗记录等小批量交易的价值，但是大批量数据库呢？

什么是区块链？

区块链依靠密码学来允许一组计算机在不需要中央参与者的情况下更改全局记录。

去除中间商可以降低几乎每个部门的成本。

区块链是一个分类帐，它按时间顺序或“链”记录一组称为“块”的数据所发生的一切。

作为一种货币，这是一项重要功能，因为它允许用户确保他们的数字货币是独一无二的，就像钱包中的每张纸币都是独一无二的一样。

“区块链技术将成为我们创造资产的方式，因为它允许你在不复制的情况下传输数字信息，”构建区块链网络的 Chain.com 的首席执行官 Adam Ludwin 说。

区块链可用于跟踪各种信息的历史并保持其价值，例如，医生可以使用它来更新医疗记录。

由于对区块链的每次更改都是在整个网络中同时进行的，因此不会丢失任何信息，并且由于更改无法撤消，系统保持其透明度。需要一个特殊的密钥来对每个块进行更改，因此个人可以通过保护该密钥来保证他们的记录安全。

我对数据库设计比较陌生，我决定制作自己的假设数据库以进行实践。但是，我无法对其进行建模和规范化，因为我认为存在许多多对多 (M:N) 关系。

一般场景描述

该数据库旨在保留有关在塞尔达系列中工作过的各种人物的数据。我想跟踪的控制台（S） ，一个游戏可以玩上，员工是曾在部分游戏的发展，乔布斯的员工有（很多员工在不同的工作职位在多个游戏等）

商业规则

• 多个员工可以在多个游戏上工作。
• 多个游戏可以在同一个控制台上。
• 多个控制台可以是同一个游戏的平台。
• 多个员工可以拥有相同的Job。
• 一个Employee可以有多个Jobs。
• 一个游戏可以有多个员工。
• 一个游戏在它的开发过程中可以有多种类型的工作
• 多个游戏可以附加相同类型的工作。
• 一个控制台可以有多个人在处理它。
• 一个人可以在多个控制台上工作。

属性名称和样本值

• Employee Name，可以分为First …