1

我正在构建一个 PHP 应用程序来使用客户端数据预填充第三方 PDF 帐户表单，并且在数据库设计上陷入困境。

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

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

这也意味着在更新时检查行是否存在以决定脚本是否需要执行 INSERT、DELETE 或 UPDATE 的大量额外查询，而如果它都在一行中，它基本上只是一个 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,信任名称、信任日期、结算银行、结算帐户、结算 bsbindividual_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，结算银行，结算账户，结算b​​sbindividual_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，结算银行，结算账户，结算b​​sb

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

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

4

5 回答 5

2

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

  1. OLTP 系统

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

  2. OLAP/DSS 系统：

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

请在此处阅读以了解这些内容和主要区别的简短描述。 OLTP 与 OLAP

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

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

我的建议是：

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

于 2013-08-20T00:56:54.957 回答
1

通常我对性能进行规范化然后反规范化。然而

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

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

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

我的用户很高兴输入所有这些表格（我不会）

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

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

于 2013-08-20T01:01:48.037 回答
1

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

于 2014-02-21T22:01:40.263 回答
0

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

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

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

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

于 2013-08-20T12:08:34.713 回答
0

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

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

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

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

正常化的基本原理一直在继续，但我希望我能不费吹灰之力。

于 2013-08-20T01:42:24.160 回答