MySQL 规范化或非规范化

Question

我正在构建一个 PHP 应用程序来用客户数据预填充第三方 PDF 帐户表单，但我在数据库设计上遇到了困难。

当前的表单有大约 70 个字段，这似乎太多了，无法设置为单独的列，尤其是有些（即公司/信托信息）与客户需要的帐户类型无关。

我尝试过规范化，但似乎会有很多连接，并且还需要多个子查询来处理多个地址等问题。

这也意味着在更新时检查行是否存在以决定脚本是否需要执行 INSERT、DELETE 或 UPDATE 的大量额外查询，而如果它们都在一行中，则基本上只是每次都要更新。

不确定这是否有帮助，但这里列出了大部分字段：

id、account_type、account_phone、account_email、account_designation、account_adviser、account_source、account_complete、 account_residential_unit_number, account_residential_street_number, account_residential_street_name, account_residential_street_type, account_residential_suburb, account_residential_state, account_residential_postcode, account_postal_unit_number, account_postal_street_number, account_postal_street_name, account_postal_street_type, account_postal_suburb, account_postal_state, account_postal_postcode, individual_1_title、individual_1_firstname、individual_1_middlename、individual_1_lastname、individual_1_dob、individual_1_occupation、individual_1_email、individual_1_phone、 individual_1_unit_number，individual_1_street_number，individual_1_street_name，individual_1_street_type，individual_1_suburb，individual_1_state，individual_1_postcode， individual_2_title、individual_2_firstname、individual_2_middlename、individual_2_lastname、individual_2_dob、individual_2_occupation、individual_2_email、individual_2_phone、 individual_2_unit_number，individual_2_street_number，individual_2_street_name，individual_2_street_type，individual_2_suburb，individual_2_state，individual_2_postcode， 公司名称，公司日期， company_unit_number, company_street_number, company_street_name, company_street_type, company_suburb, company_state, company_postcode, 信任名称，信任日期， 结算银行，结算帐户，结算b​​sb

最多需要处理大约 200,000 个应用程序，一旦数据进入数据库，它就不会经常更改，如果有的话 - 不确定这是否相关？

所以真的只是想找出最聪明的方法来设计它，即使它只是一个名称或需要进一步研究的主题。

Answer 1

一般而言，您可以将数据库分为两大类：

1. OLTP 系统

   在线事务处理系统通常是写密集型的，即与数据读取相比，更新量很大。该系统通常是所有范围的业务用户（例如数据捕获、管理等）使用的日常应用程序。这些数据库通常被标准化到极端，然后为了某些领域的性能提升而变得士气低落。

2. OLAP/DSS 系统：

   在线分析处理是数据库，通常是类似系统的大型数据仓库。用于支持分析活动，例如数据挖掘、数据多维数据集等。通常，与 OLTP 相比，这些信息由更有限的一组用户使用。这些数据库通常是非常非规范化的。

请在此处阅读有关这些内容和主要区别的简短说明。 OLTP VS OLAP

关于您的 INSERT/UPDATE/DELETE 点，请阅读 MySQL ON DUPLICATE KEY UPDATE 语句，它将为您轻松解决该问题。在大多数数据库系统中，它被称为MERGE 操作。

现在我不明白你为什么担心 JOINS。我有数百万（500 000 000+）行的表，我加入了其他大小也很大的表，并且查询运行得非常快。所以设计一个数据库来消除连接并不是一个好主意。

我的建议是：

如果设计一个 OLTP 系统尽可能规范化，然后在需要时进行非规范化以提高性能。对于 OLAP 系统，请查看星型模式等，甚至不必先对其进行规范化。哦，顺便说一句，大多数 OLAP 系统通常使用 OLTP 系统作为数据源。

Answer 2

通常我会进行规范化，然后再进行非规范化以提高性能。不过

如果我没有太多的验证要做，例如有效地址，重复的个人

我不想将部分数据重复用于表单的另一个版本，例如选择现有个人、姓名和地址等

而且我不想分析它，例如查找所有提到 Fred Bloggs 的内容

我的用户很乐意输入所有这些表单（我不会）

然后我会从一开始就使用非规范化。

问题是，如果您进行规范化，那么在需要时进行非规范化是相当微不足道且风险较低的，对非规范化数据进行规范化通常意味着重复数据删除，这可能是非常痛苦的数据和设计。

Answer 3

规范化你的输入，去规范化输出。这意味着，对于报告，将您的数据提取为像 Mongo 这样的非规范化格式并将其用于查询。或者，创建某种汇总。我发现，对于大型数据集，可以从输入数据中提取报告数据以获得最佳效率。

Answer 4

我发现在非常基础的层面上使用非规范化数据非常痛苦。如果我想要统计居住在乔治亚州的人数怎么办。在您的非规范化结构中，我必须计算 ind_1_state = GA 或 ind_2_state = GA 的位置。

我想这还不算太糟糕，但是对于任何看到规范化提供的查询便利性的人来说，这是相当痛苦的。

规范化为越来越复杂的查询奠定了基础。没有它，您会发现实施更丰富的数据分析变得越来越困难。

规范化还为数据库的完整性和一致性提供了基础。如果您在一个地方（一列）有所有出现的特定事物（州缩写），您可以轻松检查并限制这些值以不允许不存在的代码。

归一化的基本原理一直在说，但我希望我能不费吹灰之力。

Answer 5

这很简单——你现在所拥有的只是一个名词汤，你已经把它塞进一个单独的桌子存储鞋盒里，并在每行的开头粘上一些 ID。

创建某种模式。如果这更像是一个 OLAP——并且您决定使用星型模式——它将具有 2-5 NF 中的维度和 2-6 NF 中的事实。对于 OLTP（或不同的仓库模型），目标是 BCNF - 6NF。

我认为您在这里甚至没有 1NF，在开头粘贴该 ID 并不能算作防止重复。因此，即使您想这样做，也不能从这一点反规范化 :) -- 好吧，也许您可​​以在某处放置一些逗号分隔的列表，以使事情绝对不在 1NF 中。

联接是关系数据库的作用，所以不用担心。