房间：@Embedded 与 @TypeConverters

Question

如果我们在 Room 中有 @Entity，其中有复杂的对象作为字段，我们可以使用 2 种方法：

@Embedded - 据我了解，如果您使用此注释标记字段，那么 Room 会将对象内部的所有字段保存为实体本身的字段，然后正确检索所有内容。

@TypeConverters - 在这里我们编写自己的转换器，在大多数情况下归结为通常将对象解析为 Json 字符串。

其实问题：

根本区别是什么？为什么不到处写@Embedded 而不用担心转换器呢？什么时候自己写转换器比较好，什么时候用@Embedded比较好，这些方法的优缺点是什么？

Answer 1

如果我们在 Room 中有@Entity，其中有复杂的对象作为字段，我们可以使用 2 种方法

实际上这里还有另一种方法要提到 - 将复杂对象保存在单独的表中并使用外键链接到它（像往常一样使用id 和Int 或Long 类型，通常是自动生成的）。

• 如果复杂对象有自己的值并与其他对象有多个连接，请考虑使用单独的表和外键。示例：您有复杂对象 User 和另一个对象 - UserGroup（和字段：user）和 Document（字段：author）。使用单独的表格User，您可以只在一个地方更改用户名，而无需触摸另外两个表格（但您应该使用@Embedded 方法进行操作）。
• Type-converter 的广泛使用用例 - 将类型 Date 转换为整数，因为 Sqlite 不知道如何使用自己的类型系统保存此类型。 @Embedded 在这种情况下没有帮助。
• Type-converter 的另一个广泛使用的用例 - 持久保存在数据库复杂的嵌套结构中，通常来自后端 API（JSON 序列化）。但是，如果您以后决定独立处理这些嵌套结构的一部分（例如查询它们），这种方法就很脆弱。
• Type-converter 的一个更广泛使用（就我的口味而言 - 使用过多）的用例是在一个字段中保留一些对象的列表或数组。但这种方法通常可以用单独的表和外键代替（如果列表中的这些对象有自己的值）。
• 如果在多个@Entity 中您在同一个复杂对象上使用@Embedded，则表明您应该考虑使用单独的表和外键的选项，因为它浪费空间并且在某种程度上违反了数据库表的原则'标准化。例如，如果某个复杂对象有 N 个字段，而您在另外两个表中将其用作 @Embedded 字段，这意味着 SQLite 在这两个表中生成了 N 个额外的列。
• 应该提到@Embedded 广泛用于带有@Relation 的Room 的数据类（ROOM 的JOIN 类似物）。在那里，它们真的很有帮助，并且对保持这些数据类的代码简洁明了有很大帮助。这样，@Embedded 不会像在使用 @Entity 注释的类中使用它时那样，向表的结构添加任何重复（因为它只影响内存中的对象）。

Answer 2

实际区别在于，@TypeConverter 使用同一张表，@Embedded 使用单独的表。即使@TypeConverter 可以被滥用来序列化/反序列化 JSON，这仅在不需要查询其中的值时才有意义 - 但是一旦想要查询该数据，它的工作量就会大大减少，当它由一个实际的表支持，可以针对该表运行 SQL（而不是遍历所有记录并解码 JSON）。实际上 JSON 是一种数据格式，而不是一种数据类型。

以 WordPress 的 post-meta 为例……这也是存储在 SQL 数据库中的 JSON。这也是技术上可行的，但这就是性能低于标准的原因。

正确使用@TypeConverter 将例如。正在从String 转换为BigDecimal。