房间数据库和交易
Room database and transactions
我是数据库方面的新手，我正在研究 android 房间数据库的交易。使用 RoomDatabase.withTransaction 时 documentation 表示
Room will only perform at most one transaction at a time, additional transactions are queued and executed on a first come, first serve order.
根据我的理解，这意味着事务基本上与锁定我想要的每个代码块相同的事情 运行 互斥体内部的事务（我认为这样做是因为 Isolation).但是我也注意到这个限制只适用于每个数据库。例如，如果我创建 MyDatabaseOne 和 MyDatabaseTwo，事务可以 运行 异步进行。我还注意到来自 MyDatabaseOne 和 MyDatabaseTwo 的事务似乎可以嵌套。
所以我的问题是，为每个 table 使用单独的数据库有什么缺点？它是否限制了使用连接的能力？这样做是否会增加并发 运行 查询的能力（例如长 运行ning 事务）？
编辑：
我想我会把它放在这里以防有人偶然发现这个问题。 documentation 的一个重要考虑因素如下。
Note: If your app runs in a single process, you should follow the singleton design pattern when instantiating an AppDatabase object. Each RoomDatabase instance is fairly expensive, and you rarely need access to multiple instances within a single process.
So my questions are, what is the downside of just using a separate database for each table?
Does it restrict the ability to use Joins?
是的，除非你 attach 一个到另一个，否则它们是单独处理的单独文件，连接将不起作用（尽管我相信你可以通过使用 IN 在某种程度上模拟连接）。
如果有附加数据库，则可能必须使用架构名称（给附件或主数据库的名称），因此连接可能会更复杂一些。
如果附加，那么我相信事务基本上以相同的方式工作以包含附加的数据库，因此并发性是相同的。即 link 包括：-
- 涉及多个附加数据库的事务是原子的，假设主数据库不是“:memory:”并且 journal_mode 不是 WAL。如果主数据库是“:memory:”或者如果 journal_mode 是 WAL，那么事务在每个单独的数据库文件中继续是原子的。但是，如果主机在更新两个或多个数据库文件的 COMMIT 中间崩溃，其中一些文件可能会得到更改，而其他文件可能不会。
我是数据库方面的新手，我正在研究 android 房间数据库的交易。使用 RoomDatabase.withTransaction 时 documentation 表示
Room will only perform at most one transaction at a time, additional transactions are queued and executed on a first come, first serve order.
根据我的理解，这意味着事务基本上与锁定我想要的每个代码块相同的事情 运行 互斥体内部的事务（我认为这样做是因为 Isolation).但是我也注意到这个限制只适用于每个数据库。例如，如果我创建 MyDatabaseOne 和 MyDatabaseTwo，事务可以 运行 异步进行。我还注意到来自 MyDatabaseOne 和 MyDatabaseTwo 的事务似乎可以嵌套。
所以我的问题是，为每个 table 使用单独的数据库有什么缺点？它是否限制了使用连接的能力？这样做是否会增加并发 运行 查询的能力（例如长 运行ning 事务）？
编辑：
我想我会把它放在这里以防有人偶然发现这个问题。 documentation 的一个重要考虑因素如下。
Note: If your app runs in a single process, you should follow the singleton design pattern when instantiating an AppDatabase object. Each RoomDatabase instance is fairly expensive, and you rarely need access to multiple instances within a single process.
So my questions are, what is the downside of just using a separate database for each table? Does it restrict the ability to use Joins?
是的，除非你 attach 一个到另一个，否则它们是单独处理的单独文件，连接将不起作用（尽管我相信你可以通过使用 IN 在某种程度上模拟连接）。
如果有附加数据库，则可能必须使用架构名称（给附件或主数据库的名称），因此连接可能会更复杂一些。
如果附加，那么我相信事务基本上以相同的方式工作以包含附加的数据库，因此并发性是相同的。即 link 包括：-
- 涉及多个附加数据库的事务是原子的，假设主数据库不是“:memory:”并且 journal_mode 不是 WAL。如果主数据库是“:memory:”或者如果 journal_mode 是 WAL，那么事务在每个单独的数据库文件中继续是原子的。但是，如果主机在更新两个或多个数据库文件的 COMMIT 中间崩溃，其中一些文件可能会得到更改，而其他文件可能不会。