postgresql - 列数过多的表的缺点

Question

我有一些数据需要放入 PostgreSQL 数据库中。这些数据与学校有关。所以有很多与学校相关的属性，主要是小整数、 float 或小文本。所有数据每年都在变化。所以我正在创建一个名为 YearlyData 的实体并将属性放在那里。但问题是，属性的​​数量在 50-60 左右。现在这些不能归一化，因为它们是学校本身的普通属性。所以我在道德上不能将它们分成表格。但我不确定这是否会影响我的表现。

我可以尝试对这些数据进行分类并将它们放在单独的表中，然后从 YearlyData 表中指向它们。但是我猜，然后尝试使用 20-30 多个参数搜索学校会导致大量的连接。我也不确定这是否会影响我的表现。

有专家建议吗？

Answer 1

这里有几点需要考虑:

• 属性列表是否随时间显着变化
• 属性列表是否需要自定义用户定义的属性
• 不同的学校是否有不同的属性(即许多属性只适用于一所或几所学校)？

如果其中任何一个为真，您可能会考虑使用属性存储方法 like EAV, hstore, json fields, xml fields, etc .

如果不是 - 如果您有一个相当静态的属性列表，其中大多数属性对大多数行都有意义 - 那么将它们作为 60 个单独的列并不是真正的问题。为通常搜索的属性集添加索引(包括部分索引和复合索引等)会更容易，而且搜索(尤其是针对许多不同属性的搜索)将快很多。

另请参阅:Database design - should I use 30 columns or 1 column with all data in form of JSON/XML?

还有一个可供您使用的折衷选项:一个包含您经常查找的最重要详细信息的主表，以及一个用于属性逻辑分组的副表。说:

yearly_summary (
    yearly_summary_id serial primary key,
    school_id integer,
    total_students integer,
    ...
) 

加上

yearly_student_stats(
    yearly_summary_id integer primary key references yearly_summary(yearly_summy_id) on delete cascade,
    ...
)

等integer primary key 也是一个foreign key 意味着您与另一个表具有强制的 1:1(可选)关系。如果您有一些可以聚集到边表中的属性逻辑分组，则此方法会很有用。

如果再多想想也没有揭示出确实对正常化有意义的事情，我也会感到惊讶。您是否有 year7_blah、year8_blah、year9_blah 等列？如果是这样:非常适合标准化。