这可能是一个基本的问题，但我很好奇，设计一个联合类型的数据库，最合理的 "首选 "方式是什么。
我的意思是考虑一个表 Post 其中只有1个附加内容，且附加内容可以是以下类型 video, audio, pdf, text 或其他什么。 规范化的方式是为这些内容类型分别建立一个表。但是需要有一个连接表来查询其他所有的表。type 字段，表示内容的类型。
也就是说，在查询初始表的时候，需要对其中的每一个进行查询。
另一种处理方式是在厨房的水槽中设置一个 content 表上有一个类型字段。
我这样问是因为我对数据库设计不是特别精通。 我很好奇，这样结构的数据，正常的模式是什么？
这种 "一之 "的建模方式是很棘手的。 有些数据库内置了对这种功能的支持，比如继承。
一种方法是有一个 attachments 表，并将所有的表合并成一个表。 这样就会有一些列，如。
attachments_idtype check type in ('video', 'audio', . . .)更常见的是，其中的每一个都会是一个单独的实体，因为描述它们的列会有很大的不同--而且往往有自己的关系。 在这种情况下，针对少数类型的简单方法是为每一个类型单独设置一列，同时有一个约束条件，即最多不能有一个 NULL:
check ( (case when video_id is not null then 1 else 0 end) +
(case when audio_id is not null then 1 else 0 end) +
. . . <= 1
)
这允许正确声明外键关系。
另一种方法是在此基础上的变体。 假设所有的id列都具有相同的类型，那么使用列。
attachment_type varchar(255) check (attachment_type in ('video', 'audio', . . .),
attachment_id int
类型决定了 id，但数据库不会对此进行验证。
而另一种方法是一种更复杂的继承模式，它涉及到为每个实体建立单独的表，以及每个表的类型。 然后设置一个 attachments 桌子。 这看起来像。
attachments_id int generated always as identity primary key,
attachment_type varchar(255) check (attachment_type in ('video', 'audio', . . .),
unique (type, attachments_id)
然后
video_id int primary key,
type varchar(255) generated always as
foreign key video_id references (type, attachments_id)
以此类推的其他表。 这就建立了一个外键关系到 attachments 并确保类型匹配。