Database 数据库体系结构方面

例如，我有3种类型的实体，让我们把它命名为Offer。所以，可以是接受报盘、拒绝报盘和未付报盘

接受要约：

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

DeclineOffer：

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

悬而未决的报价：

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

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

空缺表：

- ID
- VacancyName
- OfferID

所以，这些实体有一些公共字段（在所有3个实体中），一些公共字段仅在2个实体之间，每个实体都有一套唯一的字段

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

一张普通的桌子提供 优点：

a） 易于开发

b） 明确并理解与空缺表的关系

缺点：

a） 某些字段将被标记为可空，即使它们不是空的 可为空的用例。例如，想象第一次联系日期和 对于AcceptOffers和，LastContactDate不可为空 悬而未决的报价。但我们必须将其标记为可空以允许存储 下线报价。因此，我们必须编写规则来检查AcceptOffer（和 DeclineOffers）没有可为空的FirstContactDate和LastContactDate

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

三个表（每种实体类型一个表）

优点：

a） 更清晰和“适当”的体系结构

缺点：

a） 更复杂的体系结构，以建立空缺之间的关系 这三张桌子各一张。我甚至无法想象没有它怎么办 还有一个表和此表的其他规则

---

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

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

如果您认为它们太不一样，我会说-创建单独的表。如果你希望他们分享很多东西，那就选一张桌子吧

这种情况没有经验法则：）

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

此外，还必须考虑性能。如果有太多的字段带有索引，则会减慢所有操作（选择除外）。因此，您可能希望在这些字段上创建函数索引以避免瓶颈