我有一些数据想存储在表中。该数据是一个项目列表,其中包含
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
中存储一行。您只询问如何存储它们,您没有确定需要进行的任何查询。但是缺乏有关特定查询的任何信息,您应该默认使用如上所述的规范化表结构。
如果您想针对某些特定查询进行优化,您可以选择非规范化,但要做到这一点,您必须牢记特定查询。在知道要优化的查询之前,您无法选择非规范化的方式。
请记住,如果您针对一种类型的查询进行优化,这将以牺牲其他类型的查询为代价。
标准化是在可以合理效率运行的查询类型方面保持灵活性的最佳方式。