Когда закрывать соединение дб на андроиде? Каждый раз после завершения вашей операции или после выхода из приложения

44

У меня есть приложение для Android, которое часто обращается к локальному sqlite3 db для рассмотрения производительности, поэтому я всегда держу соединение открытым. Но один из моих друзей рекомендовал мне открыть/закрыть соединение для каждой операции.

1) Что думают ваши парни об этих двух методах? минусы/плюсы. 2) Я провел некоторое тестирование и обнаружил, что соединение с БД не имеет слишком много накладных расходов. Накладные расходы на производительность соединения с БД зависят от размера БД?

  • 0
    Существует компромисс, я бы сказал, каждый раз, когда деятельность с операциями с БД, а не с самими приложениями, умирает ?!
  • 0
    Может быть, лучший ответ: не закрывайте его, если нет необходимости. stackoverflow.com/a/7739454/423105
Теги:
database
connection

4 ответа

31
Лучший ответ

Я не знаю никаких штрафов за производительность при частом закрытии/открытии базы данных (независимо от ее размера). Я думаю, что ответ на этот вопрос также зависит от того, какой тип приложения обращается к базе данных.

Многократно вы запрашиваете базу данных?
Тогда, кажется, исправлено, чтобы оно было открыто.

Вы извлекаете разные данные каждый раз при получении чего-то?
Опять же, кажется разумным оставить его открытым (так как вы не будете получать кеширование данных).

Есть ли другие приложения, обращающиеся к одной и той же базе данных?
Если существует риск для concurrency или проблем с блокировкой, возможно, было бы разумно закрыть базу данных после завершения чтения/записи с/на нее.

В общем, я бы сказал, что вы можете получить больше данных кэширования, чем оставлять базу данных открытой (закрывать ее) при оптимизации производительности.

  • 0
    Спасибо, ДБМ. Мое приложение является единственным, кто имеет доступ к БД, и он сделал много повторных запросов. Мне кажется, всегда держать БД открытой - лучший выбор. Но не могли бы вы более подробно рассказать о приросте производительности за счет «кэширования данных», я не совсем уверен в том, что база данных sqlite сделала под землей.
  • 1
    Я предполагаю (возможно, ошибочно), что вы запрашиваете базу данных, считываете нужные вам значения из возвращенного объекта Cursor и затем выбрасываете его. В следующий раз, когда вам понадобятся данные, вы снова пройдете ту же процедуру. Теперь предположим, что природа полученных вами данных не потребует обновления между последовательными запросами к базе данных. Тогда было бы альтернативой прочитать из базы данных один раз и сохранить значения в локальном HashMap или что-то еще. Доступ к структуре данных «в памяти» («кэшированные» данные) обычно намного быстрее, чем повторный запрос к базе данных.
Показать ещё 1 комментарий
6

Если вы используете базу данных в памяти, тогда ваши данные будут удалены при закрытии соединения.

Возможно, это был крошечный крен, но он меня просто поймал.

  • 2
    На самом деле это действительно хороший ответ. Я только недавно имел успешный опыт использования базы данных в памяти в качестве инфраструктуры кэша (где я явно хотел сбросить кэш при выходе) ...
  • 0
    Как только вы открываете db / соединение, оно все равно кэшируется.
1

В документации указано, что соединение может быть открыто до тех пор, пока оно вам понадобится. И может быть закрыт методом onDestroy(). Ссылка документации

Постоянное подключение к базе данных:

Так как getWritableDatabase() и getReadableDatabase() являются дорогими вызов, когда база данных закрыта, вы должны оставить свою базу данных соединение открыто до тех пор, пока вам, возможно, понадобится доступ к нему. Как правило, оптимально закрыть базу данных в onDestroy() вызывающая активность.

    @Override
    protected void onDestroy() {
        mDbHelper.close();
        super.onDestroy();
    }
1

В качестве дополнения открытие и закрытие соединения настолько часто может привести к тому, что вы столкнетесь с известными исключениями SQLite, если вы получите доступ к db из нескольких потоков.

См., если вы обращаетесь к db из нескольких потоков даже по одному соединению, и поскольку эти операции не являются атомарными, вы можете попытаться обновить db, который был закрыт непосредственно перед другим потоком.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню