1M 行，1 个表，几列 vs 300 个表，3000 行，几列 vs 300 列，3000 行，1 个表？答案

【问题标题】：1M rows, 1 table, few columns vs 300 tables, 3000 rows, few columns vs 300 columns, 3000 rows, 1 table?1M 行，1 个表，几列 vs 300 个表，3000 行，几列 vs 300 列，3000 行，1 个表？
【发布时间】：2016-01-19 08:19:13
【问题描述】：

我已尝试四处寻找解决此问题的最佳方法，但我找不到此类问题的任何先前示例。

我正在建设一个基于超本地化的互联网购物中心，该区域分为大约 3000 个区域。每个区域拥有大约 300 件物品。它们是相似的项目，但每个区域可以略有不同。我需要获取每个区域的“可用项目”列表。

插入速度不是问题，主要是根据“区域”值获取物品。为此类实例设置数据库的最有效方法是什么？

1M 行的表如

标识 |专区 |项目 |有用
1 | 1 | 1 |是的
2 | 1 | 2 | N
...
1262| 4 | 35 |是的
300 个表，3000 行，例如

表：zone1
编号 |项目 |有用
1 | 1 |是的
2 | 2 |否

表：zone4
编号 |项目 |有用
...
35 | 35 |是的
1 个表，300 列（每个项目），3000 行

标识 |专区 |项目1 |项目 2 ...
1 | 1 |是 | N ...
...
4 | 4 |是 |是的……

提前感谢您提供的任何帮助或任何线索，以便我做出决定！

【问题讨论】：

这个问题应该迁移到数据库栈交换
选项 1 或多或少是构建关系数据库以有效执行的操作。我看不出选择其他两个的理由。
这些是常见问题。答案总是：不要做很多桌子；并且不要跨列展开一系列内容。我会投票“关闭”，但它只允许我指向一个“重复”，而不是几十个。

标签： mysql database database-design database-schema

【解决方案1】：

基于意见的限制，但我们开始了；

选项 1 很可能是您想要的。
选项 2 将为您提供 300 个表来维护，因此如果您稍后需要添加一个字段，您将有 300 个表来更改，这听起来像是可维护性的噩梦。此外，300 个索引的缓存很可能比单个更大的索引更糟糕，并且在所有区域中搜索特定项目基本上是不可能的。
选项 3 将要求您更改表结构和查询以添加 300 多个项目。此外，为了能够通过 id 查找项目，您需要类似于 SELECT xx FROM yy WHERE item1=57 OR item2=57 OR ... OR item300=57 的 SQL，而 MySQL 的优化器很可能会放弃。

【讨论】：

这很清楚！谢谢你的解释！

【解决方案2】：

从关系数据库的角度来看，您应该选择第一个选项。 - 如果有一天你必须添加一个新项目或一个新区域，你将不必创建一个新列或一个新表，如果你需要删除一个项目/区域也是如此。

但从 NoSQL 的角度来看，您应该选择类似于选项 2 的表。

【讨论】：

【解决方案3】：

只需使用第一个选项。 1M 行，1 个表，几列。

【讨论】：

【解决方案4】：

第一个选项是最好的。 DBMS 会在每张表和每行中产生很大的开销。另外，它们不是为多表多行的情况而设计的。

【讨论】：