我在 SQL 中对电气原理图建模时遇到了一些麻烦。我想捕获的结构是
part ??????????? pin
? ?
part_inst ?????? pin_inst
其中“inst”是“instance”的缩写。
例如，我可能part将 LM358 运算放大器pin用作 1OUT、1IN-、1IN+、GND、2IN+、2IN-、2OUT 和 V CC。然后我可能会将这部分放在原理图上，创建 apart_inst和 8
pin_insts。
忽略数据字段，我对模式的最初尝试是
create table parts (
part_id bigserial primary key
);
create table pins (
pin_id bigserial primary key,
part_id bigint not null references parts
);
create table part_insts (
part_inst_id bigserial primary key,
part_id bigint not null references parts
);
create table pin_insts (
pin_inst_id bigserial primary key,
part_inst_id bigint …postgresql foreign-key database-design referential-integrity polymorphic-associations
以下数据库架构设计/模式是否有名称？我的最终目标是找到更多关于该主题的文献。今天的粗略网络搜索太多通用词，无法确定此类事物的术语（如果存在）：
Fruit (id, farm)
Apple (fruit_id, color)
[fruit_id => Fruit.id]
Banana (fruit_id, length)
[fruit_id => Fruit.id]
Orange (fruit_id, is_seedless)
[fruit_id => Fruit.id]
FruitPack (id, destination)
FruitPackFruits (fruitpack_id, fruit_id, fruit_type)
[fruit_id => Fruit.id, fruit_type => VARCHAR]
其中fruit_type将是一个varchar 列，其中填充了诸如“Apple、Banana、Orange、Cherry”之类的值。这是某种“穷人的参照完整性”。显然，这种设计的失败之一是能够插入无法解析为有用连接的值（即：这里没有樱桃可言）。
这是此类模式的另一个示例：单个“日志（id、table_name、record_id、timestamp）”表充当各种其他表中修改时间的跟踪器。严格来说，它没有 ref 完整性，但是， (table_name, record_id) 部分应该引用另一个表中的某些记录，需要连接才能实际获取完整数据。
我将理所当然地认为模式是这里人们的某种项目组集合的充分讽刺。
问题是：这种“穷人的参照完整性”叫什么？
我不是想了解参照完整性。我想确定这个糟糕设计的名称，并进一步研究与这种常见的模式灾难有关的“让我们设计一个数据库模式”方面（例如：优点、缺点、意见、教导等）。
在以下架构中：
Collections
Upvotes
Reports
Upvotes
Reviews
Upvotes
我很想有一个Upvotes表，一个单一的"entityId"列存储要么CollectionId，ReportId或ReviewId。还将有一个枚举用于Type存储collection, report, 或review。
该entityId会一直是必需的，而逻辑将始终确保刀片在每个实施唯一性type。
这样做的好处是添加另一种类型只是扩展枚举的问题。一切都将生活在一张没有冗余的桌子上。
成本似乎是逻辑方面增加的复杂性，它包含在我的应用程序逻辑中将新实体插入表中的一个地方。
实际上，这种方法有什么问题吗？避免这种情况的其他原因是什么？
I have a MySQL database with 3 tables holding the main classes of data:
companies (company_id)
persons (person_id, company_id)
loans (loan_id, company_id)
Both a 'loan' and a 'person' belong to a company. A company can have loans and a company can have people (such as directors, employees etc.)
There are several scenarios where other data can belong to either a company, a person or a loan, such as 'notes'. For example a user can add a 'note' specific to either …
我们使用大量关联表来管理系统中各种不同对象之间的一对多关系。
为了说明这个问题，举两个例子：
users, events, ass_users_events. 在ass_users_events将只包含User_ID与Event_ID列，都与外键关系。projects, tasks, ass_projects_tasks. 在ass_projects_tasks将只包含Project_ID与Task_ID列，都与外键关系。NB1：每个对象表实际上都使用了一个自动递增整数主键和一个带有唯一索引的 UUID 列的组合，该索引是实际的记录 ID。出于这个问题的目的，我们仅使用 UUID，因此不会发生冲突。
NB2：我们使用这种格式而不是直接的外键列/索引的原因是实际情况比这个例子复杂得多，许多不同的表有许多不同的连接，我们不希望 ORM 做很多每次加载记录时进行不必要的工作。
问题是我们开始为系统中的几乎所有新对象类型为系统中的许多其他现有对象创建这些关联表，从长远来看，这似乎不可持续，我们最终会数百种关联类型。
我们正在考虑的一个潜在解决方案是摆脱所有当前的关联表，而是创建一个具有以下结构的表：obj_1_id, obj_1_type, obj_2_id, obj_2_type。每列都将被索引，可能作为复合索引（即INDEX object_1 (obj_1_type,obj_1_id)和INDEX object_2 (obj_2_type,obj_2_id)）。
上面屁股表中的示例将变为：abc,user,123,event, 和def,project,456,task。
该解决方案使我们能够灵活地在不同对象之间构建任意数量的关系类型，并且 ass 表上有足够的索引以保持性能。我的问题是，仅在连接期间使用索引与在较小的表中定义外键关系相比是否存在缺点，但可能有数百个？
编辑： 我认为下面有一些误解，所以这可能会澄清一些事情：
我使用多态对象结构，但每个对象都存储在它自己的表中，即用户、产品、类别、事件等。
至于提议的 ass 表，它将只有 4 个功能字段，具有非常简单的数据类型（加上一个ai_col作为主要数据类型）。typecols的数据类型为 varchar(10)，id 的数据类型为CHAR(32) / BINARY(16)。SELECT …