有关动态条目的数据库设计 - 一行还是多行？

Question

我一直在尝试为侧面项目设计数据库架构，但我还没有能够生成任何我熟悉的东西。我正在使用ASP.Net和LINQ进行数据访问：

我将允许用户指定最多10个“项目”。每个都有2个数字属性和1个参照属性，项目名称。

如果我将此条目放入1行，则很容易等于30多列（最小值），例如 item_1_name（ref） item_1_weight item_1_volume item_2_name ......等......

我不能简单地将这些列转换为引用表，因为每个属性的范围基本上可以是1到400 +。

我还认为，如果用户只决定在其条目中放入1个项目，那么我为该数据创建对象的方法将是静态的，因为LINQ我必须检查属性和whatnot是否为NULL并据此工作。此外，如果我想增加一个条目中允许的项目数量，那么使用它会很头疼。

我想到的另一个选择就是为每个项目创建一个行并用条目ID绑定它。所以我基本上从来没有空条目，但是我的表会变得天文数字很深但不是很宽，因为只有5个奇数列。

我的设计中是否有一些我忽略的东西/有更好更有效的方法吗？

编辑：当我说它会以天文数字增长时，我的意思就是这样：用户可以创建一个条目，每个条目很可能都有一组项目。所以说他们每天进入一个网站，他们可以有3组项目，最大项目数（10），这相当于30个项目的唯一入口。每天以该速率进行一周的输入，对于该单个用户，您可以有210行。

Answer 1

我建议您提及后一种设计，创建一个包含五列的从属表：

CREATE TABLE Items (
  user_id               INTEGER NOT NULL,
  item_id               INTEGER NOT NULL DEFAULT 1,
  numeric_property1     INTEGER,
  numeric_property2     INTEGER,
  referential_property  INTEGER,
  PRIMARY KEY (user_id, item_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
                        ON DELETE CASCADE,
  FOREIGN KEY (item_id) REFERENCES num_items(item_id),
  FOREIGN KEY (referential_property) REFERENCES some_other_table(some_column)
);

我在上面显示了一个表 num_items ，如果你想限制用户最多10个项目，它包含数字1到10：

CREATE TABLE num_items (item_id INTEGER NOT NULL );
INSERT INTO num_items (item_id) 
  VALUES (1), (2), (3), (4), (5), (6), (7), (8), (9), (10);

这种设计的优点是很容易 COUNT（）给定用户有多少项，很容易计算 MIN（）和之类的东西给定属性的MAX（），可以为引用属性强制执行外键等。

某些数据库具有将复合主键的第二部分（在本例中为 item_id ）声明为自动递增的功能，因此如果指定 entity_id 但省略 item_id 它会自动获取下一个未使用的值（但如果删除一个值则不填补空白）。你没有说明你正在使用哪个品牌的数据库，所以我会留给你弄清楚这个功能。

编辑正如Tony Andrews在回答中所说，行数不是问题。您没有说明您打算使用哪个品牌的数据库，但除非您选择MS Access等特别弱的产品，否则您可以依靠数据库轻松处理数百万行。如果您选择好索引，并编写使用这些索引的查询，效率应该不是问题。

Answer 2

使用单项表：

userId，itemIndex，isReference，numericValue，referenceValue

这样，用户999的item_3_name的值转换为

999,3，真实，空，值

你必须自己强制执行某些限制，s.a。每个用户的最大项目数等。

Answer 3

正确的数据库设计是将每个用户/项目存储在单独的行中。这将更容易使用，并删除10项的任意限制。我不会说它会增长“天文学上的深度”，会有大约10 x（用户数量）的行。