它基本上有（在我看来）两大矛盾：
我得到了它们，但基本上，如果我遵循第一个“为表示子实体的类也继承的实体实现一个自定义类”-语句，那么我的所有实体都将被放入同一张桌子。根据注意，这可能会导致性能问题。
创建一个“自定义超级实体”会对性能造成多大影响？
【问题讨论】：
标签： ios core-data database-design
您可以使用继承机制来获取默认的数据库结构。从您的链接：
如果您有许多相似的实体，您可以将公共属性分解为一个超实体，也称为父实体。
没有矛盾。该文档只是告诉您使用某个工具时数据库结构将是什么。 （并且它是用于继承的标准数据库表习惯用法。）使用实体继承机制自动声明和实现默认父子类继承功能以及父表。否则，您将手动执行任何父子类继承声明和实现。每个都有一定的性能和其他特征。
设计涉及成本和收益在多个维度之间的权衡。 “性能”本身涉及多个维度，在给定的应用程序使用模式之外没有任何意义。此处相关的其他维度包括构造和维护的复杂性。
如果您足够频繁地查询作为父级的实体，那么将所有父级数据都放在自己的表中会更好。但是，如果您在查询给定子类型时很少要求父数据，或者如果您足够频繁地同时需要子数据和父数据，那么最好在子表或表中只包含父数据。但请注意，每种设计在另一种查询中的表现都较差。
【讨论】：
首先是谈论子实体。第二个是谈论子类。这是 2 个不同的层次结构。
子实体的一个用途是，如果您有一个表格，您想在其中显示显示不同实体的单元格。通过使它们成为子实体，您可以获取父实体并返回所有子实体。这实际上是 Notes 应用程序在文件夹上方显示“所有便笺”单元格的方式，这实际上是显示 Account 实体，Account 和 Folder 都是 NoteContainer 的子实体，这是获取的内容。这确实意味着所有行都在同一个表中，但我个人没有遇到任何性能问题，但在以索引、关系或约束等其他方式修改实体时要牢记这一点。
【讨论】：
我不熟悉 SQLite 的这种怪癖，但建模基类/子类关系通常是使用不同的表完成的。有一个表表示基类，其中包含所有派生类 (Vehiclea) 共有的属性，而每个子类都有一个不同的表，其中包含该子类（汽车、火车、飞机）独有的属性。
性能并不比跨不同表规范化的任何实体好或差。
【讨论】：