核心数据设计原则

Question

我刚开始阅读指南：ref/doc/uid/TP40001075-CH30-SW1

在我看来，它基本上有两大矛盾：

​

​

我将两者都得到，但基本上，如果我遵循第一个“实现自定义类到表示子实体的类也继承”-statement的实体，那么我的所有实体都将放在同一个表中。这可能会导致性能问题，根据说明。

我会遇到多大的性能打击，它会创建一个“自定义超级实体”？

Answer 1

可以使用继承机制获得默认数据库结构。从你的链接：

如果有许多类似的实体，则可以将公共属性合并到超级实体(也称为父实体)中。

没有矛盾。文档只是告诉您，当您使用某个工具时，数据库结构将是什么。(这是用于继承的标准数据库表成语。)使用实体继承机制，将自动声明并实现默认父-子类继承功能以及父表。否则，您将手工执行任何父-子类继承、声明和实现。每一个都有一定的性能和其他特性。

设计涉及多个方面的成本和收益之间的权衡。“性能”本身涉及多个维度，在给定的应用程序使用模式之外没有任何意义。这里涉及的其他方面包括结构和维护的复杂性。

如果您足够频繁地查询作为父级的实体，那么最好在它自己的表中拥有所有父数据。但是，如果在查询给定的子类型时很少请求父数据，或者如果您足够频繁地同时需要子数据和父数据，则最好只在子表或表中包含父数据。但是请注意，在另一种查询中，每种设计的性能都更差。

Answer 2

第一种是关于子实体。第二个是子类。这是两个不同的层次结构。

子实体的一种用途是，如果您有一个表，要在其中显示显示不同实体的单元格。通过使它们成为子实体，您可以获取父实体，所有子实体都将被返回.这实际上是Notes应用程序如何显示文件夹上的"All“单元格，即实际显示帐户实体，并且帐户和文件夹都是NoteContainer的子实体，这就是获取的内容。这确实意味着所有行都在同一个表中，但就我个人而言，我没有遇到任何性能问题，但在以其他方式(例如，索引、关系或约束)修改实体时，要记住这一点。

Answer 3

我不太熟悉SQLite的这种怪癖，但是建模基类/子类关系通常是用不同的表完成的。有一个表表示基类，它包含所有派生类(Vehiclea)所共有的属性，对于每个子类有一个不同的表，这些子类包含该子类(Cars、Trains、Air平面)特有的属性。

性能并不比跨不同表的任何实体更好或更差。