#android #sql #database #arrays
#Android #sql #База данных #массивы
Вопрос:
Я разрабатываю приложение, которое при запуске настраивает курсор базы данных для отображения значений в listview. В ходе работы приложения данные в базе данных обновляются, и я постоянно обновляю курсор.
Это вроде работает, но иногда курсор отстает от обновлений базы данных, таким образом, старые данные отображаются в списке до нескольких секунд.
Было бы эффективнее, если бы я загружал все данные (приблизительно 10-20 наборов из примерно 20 строк и целых чисел в каждом) в массив объектов при запуске и записывал в базу данных только при закрытии?
Каковы затраты на запросы к базе данных по сравнению с созданием массивов объектов?
Спасибо за помощь!
Ответ №1:
Если вы не говорите много данных (миллионы строк), то стоимость (в процессоре) создания объектов в памяти для их хранения будет незначительной по сравнению со временем выполнения запроса к БД.
Ответ №2:
Это зависит от вашего определения «дорого». Если вы имеете в виду пропускную способность, постоянные запросы дороже. Каждый запрос к удаленной базе данных выполняется порядка миллисекунд, в то время как запрос к объекту в памяти занимает порядка наносекунд.
Если «дорого» означает немедленную скорость обработки без учета задержки в сети, то загрузка их всех в память будет дороже, потому что система просматривает больше информации во время действия.
В вашем случае, поскольку вы имеете дело с Android, я бы сказал, что ваш лучший выбор — это комбинация двух. Вы захотите загрузить столько данных, сколько вам может понадобиться для работы в любой момент времени. Возможно, вы захотите рассмотреть возможность создания списков смежности для данных, если это поможет с извлечением данных. Благодаря хорошей системе списков смежности вы можете запрашивать данные, которые вам скоро понадобятся, работая с данными, которые у вас есть сейчас (это помогает уменьшить влияние задержки в сети).
Что касается части обновления, если вы не собираетесь ставить свои изменения в очередь и загружать их асинхронно, вы не сможете избежать этой задержки. Просто так работает сеть. Однако, если вы МОЖЕТЕ работать асинхронно с интерфейсом, вы можете поставить изменение в очередь и указать, чтобы обновление физически происходило на уровне базы данных, пока пользователь переходит к следующей задаче.