database - 数据库架构方面

Question

例如，我有 3 种类型的实体，我们将其命名为 Offer。因此，可以是 AcceptOffer、DeclineOffer 和 OutstandingOffer。

接受提议:

- UserID
- ContactID
- Notes
- FirstContactDate
- LastContactDate
[... and 5-10 the unique fields...]

拒绝报价:

- UserID
- ContactID
- Notes
[... and 5-10 the unique fields...]

优秀报价:

- UserID
- ContactID
- FirstContactDate
- LastContactDate
[... and 5-10 the unique fields...]

另外，想象一下，我们有一个名为 Vacancy 的表，它有一个字段 OfferID 和与 Offers 的关系

空缺表:

- ID
- VacancyName
- OfferID

因此，这些实体有一些公共(public)字段(在所有 3 个实体中)，一些公共(public)字段仅在 2 个实体之间，每个实体都有一组独特的字段。

问题 - 创建关系数据库架构的最佳方法是什么？我看到两种方法:

1. 一张公用表 Offers。

优点:

a) easy to develop

b) clear and understand relationship to Vacancy table

缺点:

a) some fields will be marked as nullable even when they are not nullable for used cases. I.e. imagine that FirstContactDate and LastContactDate are not nullable for AcceptOffers and OutstandingOffers. But we have to mark it as nullable to allow storing DeclineOffers. So, we have to write rules to check AcceptOffer (and DeclineOffers) has not nullable FirstContactDate and LastContactDate.

b) many fields are unique only for one type of entity, but exist for all types

1. 三个表(每种类型的实体一个表)

优点:

a) more clear and "adequate" architecture

缺点:

a) More complex architecture to build relationships between Vacancy and each of these 3 tables. I even can't imagine how to do it without one more table and additional rules for this table

哪种方法更合适，为什么？

Answer 1

这取决于您如何估计您的模型随时间推移的偏离程度。

如果您希望它们差异太大，我会说 - 创建单独的表。如果您希望他们分享很多 - 去一张 table 。

对于这种情况没有经验法则:)

这也取决于您使用的 ORM。可能会发生，它不支持表继承，您将被迫创建三个完全不同的模型。

此外，还必须考虑性能。当您有太多带有索引的字段时，会减慢除选择之外的所有操作。因此，您可能希望在此类字段上创建功能索引以避免瓶颈。