列太多的表的缺点

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

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

有专家建议吗？

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

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

如果其中任何一个是正确的，您可能会考虑使用属性存储方法如 EAV、hstore、json 字段、xml 字段等 https://dba.stackexchange.com/a/27069/7788.

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

也可以看看：数据库设计 - 我应该使用 30 列还是 1 列且所有数据都采用 JSON/XML 形式？ https://stackoverflow.com/q/13294003/398670

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

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

plus

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（可选）关系。如果您有一些可以聚集到边表中的逻辑属性分组，则此方法会很有用。

如果再多一点思考并没有揭示出以下内容，我也会感到惊讶do正常化是有意义的。你有year7_blah, year8_blah, year9_blah等专栏？如果是这样：正常化的最佳选择。