虽然最初的问题是作为 MSSQL 数据库实现向我提出的,但我在这里讨论的是一般观点,而不是具体细节。
让我们考虑一下我有三个基表:
驱动程序
车辆
运输公司
每个表都有自己的主键和一组唯一的字段。例如,Drivers 表包含
Name
、Address
、BirthDate
等属性,而 Vehicles 表包含 LicensePlate
、VehicleType
、Brand
、Model
等属性
等等。
现在,有一个新的要求来实现 Events 表。目标是将所有事件存储在单个表中(我想这是一个任意先决条件),因为事件共享许多共同属性,例如
Type
(不可用、暂停、事故、优先请求)、DateTime from/to
、 Flags
确定事件是否有与之相关的金钱成本、公司 personnel
负责跟踪或解决该事件等等。
我看到设计这个的两个主要选项:
Events表可以具有三个可为空的字段,用作指向每个单独表的外键(即Drivers、Vehicles和TransportCompanies),以及一个单独的字段(我们称之为
EventType
)
)标识特定事件记录适用于三个相关表中的哪一个。可以使用触发器强制执行验证,以确保三个外键之一具有非 NULL 值,并且它与 EventType
中指定的值匹配。
或者,他们可以将三个不同的表统一为一个 Entities 表,该表具有唯一的主键、标识
EntityType
(驾驶员、车辆、公司等)的字段以及当前的所有字段3 个表(某些字段如 Name
可以统一,但大多数不会)。 EntityType
字段将是 EntityType 表的外键,为未来潜在的类型提供灵活性。在这种情况下,Events表被简化,因为它只需要指向Entities表的
EntityID
外键。
还可能有第三种选择:为每个 Drivers、Vehicles 和 TransportCompanies 维护单独的 Event 表。
当然,我正在简化场景,值得注意的是,这是一个遗留数据库,其中 Driver、Vehicle 和 Company 表已经作为单独的实体存在。
重申一下,我并不是在寻找针对这种特定情况的最佳解决方案,而是在没有限制并且可以从头开始设计数据库的情况下探索对此进行建模的理想方法。
“事件共享许多共同属性”并不是将它们存储在单个表中的有效理由。