数据库架构方面

Question

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

AcceptOffer：

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

DeclineOffer：

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

OutstandingOffer：

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

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

空位表：

- ID
- VacancyName
- OfferID

因此，这些实体具有一些公共字段（在所有3个实体中），某些公共字段仅在2个实体之间，并且每个实体都有一组唯一字段。

问题-创建关系数据库体系结构的最佳方法是什么？ 我看到2种方法：

1. 一张普通桌子优惠。

优点：

a）易于开发

b）清楚并了解与空缺表的关系

缺点：

a）即使某些字段在使用情况下不为空，也将被标记为可空。 即，假设对于AcceptOffers和OutstandingOffers，FirstContactDate和LastContactDate不为空。 但是我们必须将其标记为可为空，以允许存储DeclineOffers。 因此，我们必须编写规则以检查AcceptOffer（和DeclineOffers）是否具有可为null的FirstContactDate和LastContactDate。

b）许多字段仅对于一种类型的实体是唯一的，但是对于所有类型都存在

2. 三张表（每种类型的实体一个表）

优点：

a）更清晰和“足够”的架构

缺点：

a）在Vacancy和这3个表之间建立关系的更复杂的体系结构。 我什至无法想象如果没有一个表和该表的附加规则怎么做

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

Answer 1

这取决于您如何估计模型随时间的变化程度。

如果您期望它们太不同，我会说-创建单独的表。 如果您希望他们分享很多东西，那就去一张桌子。

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

另外，这取决于您使用什么ORM。 可能会发生这种情况，即它不支持表继承，并且您将不得不创建三个完全不同的模型。

此外，必须考虑性能。 如果您的字段中包含索引的字段过多，则会减慢所有操作（选择除外）的速度。 因此，您可能希望在此类字段上创建功能索引以避免瓶颈。