一个表中可以有 40 多列吗

Question

我目前正在为一个项目重新设计一些数据库。特别是有一个数据库让我有点头疼。这个想法是，对于每个 client_id 和日期（client_id + date 将是 Pri. Key），每一列都将包含我们提供的每种产品的使用情况（大约 12 种产品，并且对于每个需要存储的 Cost、Margin、Total ）。我想做这样的事情：

+-----------+------------+--------------+-------------+-------------+------+--------------+
| client_id |    date    | prod_1_Total | prod_1_Cost | prod_1_Paid | .... | prod_14_Paid |
+-----------+------------+--------------+-------------+-------------+------+--------------+
| aa1       | 2014-01-01 | 245          | 54.97       | 50.58       | ...  | 431.23       |
| ...       | ...        | ...          | ...         | ...         | ...  | ...          |
+-----------+------------+--------------+-------------+-------------+------+--------------+

我们必须注意，要存在client_id必须在给定日期进行某些活动的记录，换句话说，给定 aclient_id和 a date，其余的列不能是 all NULL，否则该记录将不会出现桌子。

在我看来，将所有这些产品合并到一个像上面这样的表中似乎是一种不好的做法，特别是当对于给定的client_id并且date其中许多将是NULL.

但是我想到的替代方案，为每个产品创建单独的表，提出了一个问题，例如计算某个日期的total_paid所有产品client_id，我们必须进行 14 次左连接，而且如果我们使用让我们说 product_1 in查询作为主要查询，我们left join反对它，结果将是不正确的，因为很可能客户端使用了几天product_x而不是product_1（MySQL 不支持全外连接）

你会推荐什么设计策略？

感谢您的建议。

Answer 1

考虑到 MySQL 仍然是一个关系数据库管理系统（如果您愿意，可以使用 RDBMS），您应该考虑以下事项：

• 您的表由它们包含的数据以及与其他表的关系定义
• 您的数据应尽可能非冗余

最后一点导致规范化的过程，这是在 RDBMS 中要做的一件非常重要的事情。

看看维基百科关于规范化的文章，对这个过程需要什么有一个基本的了解：http : //en.wikipedia.org/wiki/Database_normalization

我发现，通常，从数据库的“存储”方面退一步是个好主意。尝试查看您的应用程序、其中使用的数据模型及其关系。创建这样的抽象被称为 ERM：实体关系模型，或 ERD：实体关系图。更多信息：http : //en.wikipedia.org/wiki/Entity%E2%80%93relationship_model

特别针对您的情况：

除了您没有使用适合关系数据库的设计这一事实之外，请考虑这样一个事实：您正在创建一个非常不灵活的设计！例如，如果您将来要创建新产品怎么办？你会在表格中添加一个新列吗？你肯定会同意这是非常愚蠢的。

相反，按照以下方式创造一些东西更有意义

+-----------+-------------+----------------+
| client_id | client_name | client_address |
+-----------+-------------+----------------+
| 1         | Snake Logan | ...            |
| 2         | Mad Max     | ...            |
| ...       | ...         | ...            |
+-----------+---------- --+----------------+

+------------+---------------+---------------+
| product_id | product_desc  | product_price |
+------------+---------------+---------------+
| 1          | Silver Bullet | 14.00         |
| 2          | Hand grenade  | 7.00          |
| ...        | ...           | ...           |
+------------+---------------+---------------+

+-------------+-----------+------------+-----------------+
| purchase_id | client_id | product_id | purchase_amount |
+-------------+-----------+------------+-----------------+
| 1           | 1         | 1          | 3               |
| 2           | 1         | 2          | 1               |
| 3           | 2         | 2          | 5               |
+-------------+-----------+------------+-----------------+

我并不是说这是有史以来最伟大的设计，但它更优雅。

如果您想了解有关购买的更多信息，我建议通过将表格连接在一起来构建一个包含必要信息的视图。请不要创建像purchase_total这样的字段，我认为这将再次成为冗余数据。数据已经存在（purchase_amount 和 product_id），您应该需要计算一下（purchase_amount * product_price）。如果你愿意，你可以把它放在视图中。表用于存储数据，视图用于呈现所述数据。