java - 房间 : @Embedded vs @TypeConverters

Question

如果我们在 Room 中有 @Entity，其中有复杂的对象作为字段，我们可以使用 2 种方法:
@Embedded - 据我了解，如果您使用此注释标记字段，则 Room 会将对象内部的所有字段保存为实体本身的字段，然后正确检索所有内容。
@TypeConverters - 在这里我们编写自己的转换器，在大多数情况下归结为将对象通常解析为 Json 字符串。
其实问题是:
根本区别是什么？为什么不到处写@Embedded 而不用担心转换器呢？何时编写自己的转换器更好，何时使用@Embedded 更好，这些方法的优缺点是什么？

Answer 1

If we have @Entity in Room in which there are complex objects as fields, we can use 2 approaches

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

如果复杂对象有自己的值并且与其他对象有多个连接，请考虑使用单独的表和外键。示例:您有复杂对象 User和另外几个 - UserGroup (和字段: user )和 Document (字段:author)。使用单独的表格 User您只能在一个地方更改用户名，而无需触摸另外两个表(但您应该使用 @Embedded 方法进行操作)。

Type-converter 的广泛使用用例- 正在转换类型Date为整数，因为 Sqlite 不知道如何使用它自己的类型系统来保存这种类型。 @Embedded在这种情况下没有帮助。

Type-converter 的另一个广泛使用的用例- 坚持数据库复杂的嵌套结构，通常来自后端 API(JSON 序列化)。但是，如果您以后决定独立处理这些嵌套结构的一部分(例如，查询它们)，这种方法是脆弱的。

Type-converter 的一个更广泛使用(就我的口味而言 - 使用太多)的用例在一个字段中持久化一些对象的列表或数组。但通常这种方法可以用单独的表和外键代替(如果列表中的这些对象有自己的值)。

如果您在多个@Entity 中使用 @Embedded在同一个复杂对象上，这是一个标志，您应该考虑使用单独的表和外键的选项，因为它浪费空间并且在某种程度上违反了 DB 表的规范化原则。例如，如果某个复杂对象有 N 个字段，而您将其用作 @Embedded其他两个表中的字段，这意味着 SQLite 在这两个表中生成了 N 个额外的列。

值得一提的是@Embedded广泛用于带有@Relation 的Room 的数据类(ROOM 的JOIN 类似物)。在那里，它们真的很有帮助，并且对保持这些数据类的代码简洁明了有很大帮助。这样，@Embedded 不会像在使用 @Entity 注释的类中使用它时那样，向表的结构添加任何重复(因为它只影响内存中的对象)。