什么是SQLite的在Android上的最佳实践？ [英] What are the best practices for SQLite on Android?
问题描述
在一个Android应用程序执行的查询上一个SQLite数据库时，你会被认为是最好的做法是什么？
What would be considered the best practices when executing queries on an SQLite db within an Android app?
它是安全运行的插入，删除，并从的AsyncTask的doInBackground选择查询？或者我应该使用UI线程？我想，数据库查询可以重，而不应使用UI线程，因为它可以锁定应用程序 - 从而导致ANR
Is it safe to run inserts, deletes and select queries from an AsyncTask's doInBackground ? Or should I use the UI Thread ? I suppose that db queries can be "heavy" and should not use the UI thread as it can lock up the app - resulting in an ANR.
如果我有几个AsyncTasks，如果他们共享一个连接，或者他们应该打开一个连接各？
If I have several AsyncTasks, should they share a connection or should they open a connection each?
是否有任何的最佳做法，这些方案？
Are there any best practices for these scenarios?
推荐答案
插入，更新，删除和读取是从多个线程通常不错，但布拉德的答案是不正确的。你必须小心你如何创建连接并使用它们。在有些情况下你的更新调用将失败，即使你的数据库没有遭到损坏。
Inserts, updates, deletes and reads are generally OK from multiple threads, but Brad's answer is not correct. You have to be careful with how you create your connections and use them. There are situations where your update calls will fail, even if your database doesn't get corrupted.
基本的答案。
在SqliteOpenHelper对象保存在一个数据库连接。这似乎为您提供读写连接，但它确实没有。调用只读，你会得到写入数据库连接不管。
The SqliteOpenHelper object holds on to one database connection. It appears to offer you a read and write connection, but it really doesn't. Call the read-only, and you'll get the write database connection regardless.
所以，有帮手例如，一个数据库连接。即使你从多个线程使用它，一次一个连接。该SqliteDatabase对象使用Java锁保留访问序列化。因此，如果100个线程有一个数据库实例，调用实际的磁盘上的数据库的序列化。
So, one helper instance, one db connection. Even if you use it from multiple threads, one connection at a time. The SqliteDatabase object uses java locks to keep access serialized. So, if 100 threads have one db instance, calls to the actual on-disk database are serialized.
所以，有帮手，一是数据库连接，这是连载于Java的code。一个线程，线程1000，如果你使用它们之间共享1帮手例如，所有的数据库访问code是串行。生活更美好（ISH）。
So, one helper, one db connection, which is serialized in java code. One thread, 1000 threads, if you use one helper instance shared between them, all of your db access code is serial. And life is good (ish).
如果您尝试写入来自在同一时间不同的实际连接的数据库，一会失败。它不会等到第一个完成，然后写。它根本不会写你的变化。更糟的是，如果你不叫正确的版本插入/更新对SQLiteDatabase，你不会得到一个异常。你将只能收到一条消息，在你的LogCat中，这将是它。
If you try to write to the database from actual distinct connections at the same time, one will fail. It will not wait till the first is done and then write. It will simply not write your change. Worse, if you don’t call the right version of insert/update on the SQLiteDatabase, you won’t get an exception. You’ll just get a message in your LogCat, and that will be it.
所以，多线程？使用一个帮手。期。如果你知道只有一个线程会写，你可以使用多个连接，和你的阅读速度会更快，但买家当心。我没有测试过那么多。
So, multiple threads? Use one helper. Period. If you KNOW only one thread will be writing, you MAY be able to use multiple connections, and your reads will be faster, but buyer beware. I haven't tested that much.
下面是一个博客帖子有更为详细和示例应用程序。
Here's a blog post with far more detail and an example app.
- Android的SQLite的锁定（更新链接2012年6月18日）
- <一个href="https://github.com/touchlab/Android-Database-Locking-Collisions-Example">Android-Database-Locking-Collisions-Example通过在GitHub上touchlab
- Android Sqlite Locking (Updated link 6/18/2012)
- Android-Database-Locking-Collisions-Example by touchlab on GitHub
格雷和我实际上结束了ORM工具，根据脱下Ormlite，这与Android数据库实现作品本身，并遵循安全创建/调用结构，我在此博客文章中。这应该是出很快。一起来看看。
Gray and I are actually wrapping up an ORM tool, based off of his Ormlite, that works natively with Android database implementations, and follows the safe creation/calling structure I describe in the blog post. That should be out very soon. Take a look.
在此期间，有一个后续的博客文章：
In the meantime, there is a follow up blog post:
也是由$ P $中的 2point0 的检出叉pviously提到锁定例如：
Also checkout the fork by 2point0 of the previously mentioned locking example:
- <一个href="https://github.com/2point0/Android-Database-Locking-Collisions-Example">Android-Database-Locking-Collisions-Example通过在GitHub上2point0
这篇关于什么是SQLite的在Android上的最佳实践？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
