列太多的表的缺点

Question

我有一些数据需要放入 PostgreSQL 数据库中。这些数据与学校有关。所以有很多与学校相关的属性，大部分是小整数、浮点数或小文本。所有数据每年都会发生变化。所以我正在创建一个名为 的实体YearlyData并将属性放在那里。但问题是，属性数量在50-60左右。现在这些不能正常化，因为它们是学校本身的简单属性。所以从道德上讲我不能将它们分成表格。但我不确定这是否会损害我的表现。

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

有专家建议吗？

Answer 1

这里有一些事情需要考虑：

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

如果其中任何一个是正确的，您可能会考虑使用属性存储方法，例如 EAV、hstore、json 字段、xml 字段等。

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

另请参阅：数据库设计 - 我应该使用 30 列还是 1 列且所有数据均采用 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等栏目吗？如果是这样：正常化的最佳候选者。