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 系统作为数据源。