大桌子还是多个单独的桌子？ （数据库设计问题）

Question

这是一个数据库设计问题。

我想构建发票Web应用程序，发票可以包含许多项目，每个用户都可以拥有可以存储并选择添加到发票项目的产品项目的库存清单。

我的问题是：
 1.我是否应该在一张桌子下使用我的应用程序存储所有用户的所有产品库存？或者为每个用户创建一个单独的产品库存表？  这甚至可能吗？

1表更容易，但是如果这个单个表变得太大，我会有问题吗？ （主键INT）。

Answer 1

每个用户的表格是个坏主意。将所有广告资源保存在一个表格中，以userid键入。对于任何工业级DBMS来说，这个表必须非常庞大（你应该等到你有数千万行才能提出这样的问题）。

如果您最常访问用户的库存，则可以通过将userid设置为群集密钥的第一列来加速此类查询，从而迫使每个用户的库存在磁盘上聚集在一起。但是，在您观察到性能实际下降之前，请不要再考虑这些问题。

Answer 2

产品是用户生成的还是您控制它们？

无论如何，我认为你会有一个产品表和一个用户表。根据产品的来源（换句话说，如果它们是用户独有的，或者可能由用户加载，或者如果它们可由任意数量的用户访问），那么您可能会有一个将用户映射到产品的表。如果产品确实是给定用户专用的，那么仅仅存储用户ID和产品记录就足够了。

不要担心桌面大小，至少不是最初的。 SQL Server是一个功能强大的数据库工具，只需确保您具有良好的数据库规范化和正确的索引。

Answer 3

随着表格的增长，服务器的设置和布局将开始变得更加重要，您的索引选择和编写查询的方式也会变得更加重要。但是，除非您希望数百万行，否则不会有太多行，一个表的执行效果不会很好。

一般的经验法则是，表格包含数据，但 数据本身。如果您开始让表格显示谁的数据，那么您可能正在转向第二类，需要备份并考虑您正在做的事情。

Answer 4

如果每个用户拥有他们拥有/管理的一组不同的产品，则可以稍后对单个表进行分区。正如其他人所建议的那样，除非你期望数以千万计的产品，否则你不应该担心性能。

我建议从一张桌子开始。如果每个用户的产品架构相同，那么这是一种非常简单有效的设计。

但是，如果与不同用户相关的产品需要不同的架构，您最终可能会得到一个非常稀疏的表（每个记录中有很多空/ NULL字段，这会影响每个人的性能）。

一种常见的方法是EAV（实体 - 属性 - 值）表，它有三列：产品ID，属性名称和属性值。这是一个完全动态的解决方案，非常简单。但是，它使得实现声明性限制变得困难。

我对动态模式的首选方法是使static / always required字段成为permanent / table模式的一部分。动态部分可以创建为XML字段，并受XML模式（或集合）约束。以这种方式可以很好地强制执行数据完整性，并且您只需要一个字段用于额外位。

Answer 5

您的选项2有问题。 Joe Celko将此设计缺陷称为table splitting; Chris Date将其称为违反the principle of orthogonal design。