DB体系结构方面

Question

例如，我有3种类型的实体，让我们把它命名为提供。所以，可以是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和与提供的关系

空缺表：

- ID
- VacancyName
- OfferID

因此，这些实体有一些公共字段(在所有3个实体中)，一些公共字段仅在两个实体之间，每个实体都有唯一字段的集合。

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

1. 一张普通的桌子。

优点：

a)易于开发 ( b)明确和理解与空缺表的关系

缺点：

( a)一些字段将被标记为可空，即使它们对于用例来说是不可空的。例如，假设FirstContactDate和LastContactDate对于AcceptOffers和OutstandingOffers是不可空的。但我们必须将其标记为可空，以允许存储DeclineOffers。因此，我们必须编写规则来检查AcceptOffer (和DeclineOffers)是否有可空的FirstContactDate和LastContactDate。 ( b)许多字段仅对一种类型的实体是唯一的，但对于所有类型都存在。

1. 三张表格(每种实体一张表)

优点：

( a)更清晰和“适当”的架构

缺点：

( a)在空缺和这3个表中的每个表之间建立关系的更复杂的体系结构。我甚至无法想象在没有一个表和这个表的附加规则的情况下该如何做。

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

Answer 1

这取决于您如何估计您的模型将在多大程度上会随着时间的推移而发散。

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

(这类案件没有经验规则:)

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

此外，还必须考虑到业绩。当有太多的字段包含索引时，除了选择之外，这会减缓所有操作的速度。因此，您可能希望在这些字段上创建函数索引，以避免瓶颈。