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_name，company_date，   company_unit_number，company_street_number，company_street_name，company_street_type，company_suburb，company_state，company_postcode，   trust_name，trust_date，   settlement_bank，settlement_account，settlement_bsb

最需要处理的是大约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中。

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