从一个将依赖 sqlite 进行持久性的项目开始,我一直试图更好地理解使用预先支持的数据库与以编程方式生成的数据库的含义。到目前为止,我倾向于根据这个问题和iosched app db example编程方法。
这一切都很好,但在这一点上,我不确定我能否简洁地说明为什么这是一种更好的方法,尤其是长期而言。
PS:我排除了 ormlite,因为域类在一个 jar 库中,已经在其他 2 个应用程序中注释了 jpa。
从一个将依赖 sqlite 进行持久性的项目开始,我一直试图更好地理解使用预先支持的数据库与以编程方式生成的数据库的含义。到目前为止,我倾向于根据这个问题和iosched app db example编程方法。
这一切都很好,但在这一点上,我不确定我能否简洁地说明为什么这是一种更好的方法,尤其是长期而言。
PS:我排除了 ormlite,因为域类在一个 jar 库中,已经在其他 2 个应用程序中注释了 jpa。
预烘焙是可以的,但它引入了一些不太理想的过程。首先,您仍然必须创建数据库,大概是在支持表创建、列条目等的 IDE 中。然后您必须将该数据库保存在您的项目中并实现代码以将其实例化为您的应用程序数据库。
对于刚开始并且以后可以通过代码掌握更详细的详细过程的人来说,这是一个很好的第一步。
然而,这个过程提出了许多问题。首先,您已经失去了创建数据库的步骤,除非您保存了 sql 查询来创建表。它们仍然不是您可以调整和重新运行的项目的一部分。
如其他帖子中所述,您有一个重复的数据库消耗空间。数据库在适应更改和更新方面也不太灵活。
如果您喜欢单元测试,那么使用编码解决方案可以查看在数据库生成上运行测试,这可以很好地扩展到您管理数据库迁移的方式。
因此,最初冗长的代码最终更加灵活,可以更容易地进行单元测试,最终更快地采用更复杂的更改。
以我的经验,除了不使用预先创建的数据库之外,几乎没有什么不同之处,可以省去跟踪额外文件并将其包含在 .apk 文件中的麻烦。
鉴于不使用预先创建的数据库的优势仅限于上述情况,仍然存在使用它们值得额外工作的场景。一个很好的例子是预加载大量数据或复杂数据的数据库。
否则我建议不要使用预先创建的数据库。