这是一个数据库设计问题。
我想构建一个发票 Web 应用程序，一个发票可以有很多项目，每个用户可以有一个他们可以存储并选择添加到发票项目的产品项目的库存列表。
我的问题是：
1. 我应该将使用我的应用程序的所有用户的所有产品库存存储在一张表下吗？或者为每个用户创建一个单独的产品库存表？
2. 这可能吗？
1个表比较容易，但是如果这个单表太大了怎么办，会不会有问题？ （主键 INT）。
【问题讨论】：
标签： asp.net sql sql-server
每个用户一张桌子是个坏主意。将所有库存保存在一个表中，键入 userid。该表必须非常庞大才能在任何工业级 DBMS 上成为问题（您应该等到拥有数千万行时才提出此类问题）。
如果您最常按用户访问库存，则可以通过将userid 设置为聚集键的第一列来加快此类查询，从而强制每个用户的库存在磁盘上聚集在一起。不过，在您观察到性能实际下降之前，甚至不要考虑这些问题。
【讨论】：
产品是用户生成的还是您控制的？
无论如何，我认为您应该有一张产品表和一张用户表。根据产品的来源（换句话说，如果它们是用户独有的并且可能由用户加载，或者它们可以被任意数量的用户访问），那么您可能会有一个将用户映射到产品的表。如果产品确实是给定用户独有的，那么仅将用户 ID 与产品记录一起存储就足够了。
不用担心桌子的大小，至少一开始不用。 SQL Server 是一个强大的数据库工具，只要确保你有良好的数据库规范化和正确的索引。
【讨论】：
随着表的增长，服务器的设置和布局以及您对索引的选择和编写查询的方式将变得越来越重要。但是，除非您期望有 数百万 行，否则不会有太多行以使一张表表现良好。
一般的经验法则是表应该包含数据，而不是是数据本身。如果您开始让表格指出谁的数据，那么您可能会转向第二类，需要备份并考虑您在做什么。
【讨论】：
如果每个用户都有自己拥有/管理的一组不同的产品，则可以稍后对单个表进行分区。正如其他人所建议的那样，除非您期望有数千万种产品，否则您不应该担心性能。
我建议从一张桌子开始。如果每个用户的产品架构都相同，那么这是一个非常简单且高效的设计。
但是，如果与不同用户相关的产品需要不同的架构，您最终可能会得到一个非常稀疏的表（每条记录中有很多空/NULL 字段，这会影响每个人的性能）。
一种常见的方法是 EAV（实体-属性-值）表，该表具有三列：产品 ID、属性名称和属性值。这是一个完全动态的解决方案，非常简单。但是，它使声明性约束的实现变得困难。
我对动态架构的首选方法是将静态/始终必需的字段作为永久/表架构的一部分。动态部分可以创建为 XML 字段并受 XML 模式（或集合）约束。通过这种方式可以很好地执行数据完整性，并且您只需要一个字段来存储额外的位。
【讨论】：
您的选项 2 有问题。 Joe Celko 将此设计缺陷称为table splitting； Chris Date 称其违反了the principle of orthogonal design。
【讨论】：