Причины использования читаемой базы данных SQLite

Question

Класс Android SQLiteOpenHelper имеет метод для возврата читаемой базы данных, а также базы данных для чтения и записи.В настоящее время я использую только базу данных с возможностью записи и у меня нет проблем, но мне интересно, какую выгоду можно изменить на использование только для чтения, только если я читаю только в асинхронной задаче (или операции).выгоды, но я не видел никаких ссылок на фактические цифры.Кроме того, если я продолжу переключаться между читаемым и записываемым, изменение будет иметь дополнительные издержки, которые могут отбросить все преимущества производительности.

Кто-нибудь имеет реальные цифры или опыт с этим?Стоит ли реализовывать отдельный доступ?

Answer 1

Хороший вопрос. Нет номеров от меня. Ближайшее объяснение (от SQLLiteOpenHandler javadoc)

"Это (getReadableDatabase) будет тем же объектом, который возвращает getWritableDatabase (), если только для некоторых проблем, таких как полный диск, не требуется открывать базу данных только для чтения. В этом случае объект базы данных только для чтения Если проблема устранена, в будущем может произойти вызов getWritableDatabase (), и в этом случае объект базы данных только для чтения будет закрыт, а объект чтения / записи будет возвращен в будущем. "

Answer 2

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

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

Два примера, которые я могу вспомнить ...

1. Если внешний процесс может иметь ответственность за поддержание данных - в этом случае он мог «открыться» источник данных таким образом, чтобы он блокирует все, кроме «чтения» любой другой процесс на этапе технического обслуживания. В этом случае, вашему коду будет отказано в доступе, если вы запрашиваете права на чтение / запись, когда это не обязательно.
2. Риск нарушения целостности данных - хакерские атаки на системы из внешнего мира могут быть достигнуты через дыру в безопасности с использованием внутреннего кода, который имеет доступ на чтение / запись к данным, когда на самом деле требуется только доступ на «чтение».

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