我有一些数据，我想存储在一个表中。该数据是具有id(字符串)和source(字符串)属性的项目列表。我想做的是做一个表A，它有2列:source(varchar)和items(set)。假设每个源有20个项目，总共有200个项目。如果我想这样做，我就不能使用SET，因为它有64个值的限制，所以我不能在创建表时指定所有可用的项选项。
现在我们在上下文中，我想出了两个选项:
-
根据我需要的相同结构制作尽可能多的表，每个表有64个值(T1: 1-64, T2: 65-128等)-我不认为这是一个非常好的选择，但它仍然是一个选项。
-
而不是使用一个集合，使尽可能多的行作为项，作为列
source(varchar)和id(varchar)——另一个选项，我不是真的喜欢，因为我需要创建很多行，每当我需要发出请求，它可能需要通过整个表。不过还是比选项1好。
是否有一种更干净(更便宜的计算)的解决方案来实现这一点?谢谢。
您说项目有一个属性source。但是，您希望存储数据，就好像项目列表是每个源的属性一样?
这听起来真的像是项和源之间的多对多关系。这是在关系数据库中执行此操作的典型解决方案:
CREATE TABLE items ( item_id INT PRIMARY KEY );
CREATE TABLE sources ( source_id INT PRIMARY KEY );
CREATE TABLE item_sources (
item_id INT NOT NULL,
source_id INT NOT NULL,
PRIMARY KEY (item_id, source_id),
FOREIGN KEY (item_id) REFERENCES items (item_id),
FOREIGN KEY (source_id) REFERENCES sources (source_id)
);
- 每次将一个项目分配给一个源时，在
item_sources中存储一行 - 你想要多少就可以有多少
- 很容易添加另一个，只需插入一行。
- 很容易删除一个，通过删除一行。
- 很容易获取给定来源的项目。
- 很容易获取给定项目的资源。
- 很容易计数或排序，或者找出哪些项目是最受欢迎的，或者做任何你想做的事情。
您只询问如何存储它们，您没有确定需要进行的任何查询。但是由于缺乏关于特定查询的任何信息，您应该默认使用如上所示的规范化表结构。
如果你想优化一些特定的查询，你可以选择反规范化，但要做到这一点，你必须记住特定的查询。在您知道要优化的查询之前，您不能选择哪种方式进行反规范化。
请记住，如果您为一种类型的查询进行优化，这将以牺牲其他类型的查询为代价。
规范化是保持查询类型灵活性的最佳方式，您可以以合理的效率运行。