有些人提倡将对象的表示存储为单列。如果你只想存储和检索对象，然后再处理对象，这是很好的。代码本身通常可以更短。
如果您想通过SQLite的强大功能来操作嵌入到表示中的底层值（对象中的字段），那么事情可能会变得相当复杂，而且可能效率低下，因为可能缺少可用的/可用的索引，导致全表扫描的可能性高得多。
例如，如果myvalue是一个表示（通常是JSON）中的值，则要查找具有此值的行，必须使用类似于

@Query("SELECT * FROM the_table WHERE the_one_for_many_values_column LIKE '%myvalue%'")

或

@Query("SELECT * FROM the_table WHERE instr(the_one_for_may_values_column,'myvalue')

与myvalue存储在它自己的列（比如_value）中相反，则

@Query("SELECT * FROM the_table WHERE the_value LIKE 'myvalue')

• 前两种方法有一个缺陷，即如果myvalue存储在表示中的其他地方，那么该行也包括在偶数中。2除了LIKE与大小写无关之外，第三种方法是EXACT。
• 在the_value列上创建索引可以提高性能

此外，这种表示无疑会增加膨胀（值的分隔符和描述符），因此需要更多的存储空间，因为相同的数据通常会存储多次，而标准化关系方法可能只存储数据的1个示例（如果是1-M关系（不包括索引），每次重复最多8个字节）。

• 将超过32字节的膨胀和满足多对多关系所需的最大值（Map表中的8字节父级、8字节子级和两个8字节列）。

由于SQLite API使用游标（缓冲）来检索提取的数据，因此在存储需求较大的情况下，CursorWindow（由x行输出加载的有限大小的缓冲区）一次可以容纳的行数较少。此外，由于膨胀，单个行大于CursorWindow允许值的可能性也较大。
简而言之，对于对性能不太感兴趣的小型简单项目，通过TypeConverters存储表示可能是更方便、更实用的方法;对于大型复杂项目，通过相关的数据而不是嵌入在表示中的数据释放SQLite的关系方面可能是一条可行之路。