1M 行，1 table，几列 vs 300 tables，3000 行，几列 vs 300 列，3000 行，1 table？

1M rows, 1 table, few columns vs 300 tables, 3000 rows, few columns vs 300 columns, 3000 rows, 1 table?

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

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

插入速度不是问题，主要是根据"zone"的值获取条目。为此类实例设置数据库的最有效方法是什么？

  1. 1 table 具有 1M 行，例如

    编号 |专区 |项目 |有用
    1 | 1 | 1 | Y
    2 | 1 | 2 | N
    ...
    1262| 4 | 35 | Y

  2. 300 tables 3000 行如

    table: zone1
    编号 |项目 |有用
    1 | 1 | Y
    2 | 2 | N

    table: zone4
    编号 |项目 |有用
    ...
    35 | 35 | Y

  3. 1 table 有 300 列（每一项），3000 行

    编号 |专区 |项目 1 |项目 2 ...
    1 | 1 |是 | N ...
    ...
    4 | 4 |是 | Y ...

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

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

  • 选项 1 很可能是您想要的。

  • 选项 2 会给你 300 tables 来维护，所以如果你以后需要添加一个字段，你有 300 tables 来改变这听起来像是可维护性恶梦。此外，300 个索引很可能比一个更大的索引缓存更差，并且在所有区域中搜索特定项目基本上是不可能的。

  • 选项 3 需要您更改 table 结构和查询以添加 300 多个项目。此外，为了能够通过 id 找到一个项目，你需要 SQL 看起来像 SELECT xx FROM yy WHERE item1=57 OR item2=57 OR ... OR item300=57，MySQL 的优化器很可能会放弃。

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

但是从 NoSQL 的角度来看，您应该选择 tables 就像选项 2。

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

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