Мы разрабатываем приложение для Android, которое имеет множество данных («клиенты», «продукты», «заказы» ...), и мы надеваем Не хотите запрашивать SQLite каждый раз, когда нам нужна запись. Мы хотим избежать запросов к базе данных как можно больше, поэтому мы решили хранить определенные данные всегда в памяти.Лучшая практика хранения данных в памяти и базе данных в то же время на Android
Наша первоначальная идея заключается в том, чтобы создать два простых классов:
"MemoryRecord": класс, который будет содержать в основном массив объектов (строка, INT, двойной, DateTime и т.д ...), это данные из записи таблицы и все методы для получения этих данных из этого массива.
«MemoryTable»: класс, который будет содержать в основном карту [Key, MemoryRecord] и все методы для управления этой Картой и вставки/обновления/удаления записи в/из базы данных.
Эти классы будут получены для всех видов таблиц, которые мы имеем в базе данных. Конечно, есть и другие полезные методы, не перечисленные выше, но они не важны на данный момент.
Итак, при запуске приложения мы будем загружать эти таблицы из базы данных SQLite в память с помощью этих классов, и каждый раз, когда нам нужно менять некоторые данные, мы будем менять их в памяти и после этого вносить в базу данных сразу после.
Но мы хотим получить помощь/совет от вас. Можете ли вы предложить что-то более простое или эффективное для реализации такого? Или, может быть, некоторые существующие классы, которые уже делают это для нас?
Я понимаю, что вы, ребята, пытаетесь показать мне, и я благодарю вас за это.
Но, скажем, у нас есть таблица с 2000 записями, и мне нужно будет перечислить эти записи. Для каждого из них я должен запросить другие 30 таблиц (некоторые из них с 1000 записями, другие с 10 записями), чтобы добавить дополнительную информацию в список, и это пока «летает» (и, как вы знаете, мы должны быть очень быстрыми в данный момент).
Теперь вы скажете: «Просто создайте свой основной запрос со всеми этими« объединениями »и принесите все, что вам нужно за один шаг. SQLite может быть очень быстрым, если ваша база данных хорошо разработана и т. Д. .. ".
OK, но этот запрос станет очень сложным и уверенным, хотя SQLite очень быстр, он будет слишком «медленным» (2 раза в 4 секунды, как я уже подтвердил, и это не приемлемое для нас время).
Другим осложнителем является то, что в зависимости от взаимодействия с пользователем нам необходимо «повторно запросить» все записи, поскольку задействованные таблицы не совпадают, и мы должны «повторно присоединиться» к другому набору таблиц.
Итак, альтернатива - это только основные записи (это никогда не изменится, независимо от того, что пользователь делает или хочет) без соединения (это очень быстро!) И запрашивать другие таблицы каждый раз, когда нам нужны некоторые данные. Обратите внимание, что в таблице, содержащей только 10 записей, мы будем извлекать одни и те же записи много и много раз. В этом случае это пустая трата времени, потому что, несмотря на быстрый SQLite, всегда будет дороже запрос, курсор, выборка и т. Д., А не просто захват записи из своего «кэша памяти». Я хочу пояснить, что мы не планируем постоянно хранить все данные в памяти, а просто некоторые таблицы, которые мы запрашиваем очень часто.
И мы пришли к первому вопросу: что является лучшим способом «кэшировать» эти записи? Мне очень нравится сосредоточиться на этом обсуждении, а не «зачем вам кэшировать данные?«
«Мы хотим избежать запроса базы данных как можно больше, поэтому мы решили сохранить определенные данные в памяти». - Вы использовали Traceview, чтобы подтвердить, что это проблема для вашего приложения? «мы хотим получить от вас какую-то помощь/советы» - мой совет: докажите, что в первую очередь проблема. У вас очень мало оперативной памяти для работы. Построение некоторых больших рамок для решения несуществующей проблемы было бы пустой тратой усилий. Если вы продемонстрировали, что это проблема, мне бы понравился указатель на сообщение в блоге, где вы его написали, так как меня всегда интересуют результаты теста производительности. – CommonsWare
@CommonsWare: Я понимаю вашу точку зрения и полностью согласен с вами. Но, как разработчики PalmOS и .NetCF, мы уже сталкиваемся с этой проблемой раньше. В PalmOS все данные хранятся в памяти по дизайну (.pdb), и при получении данных нет проблем с производительностью. В другой раздаче, в WM мы сталкиваемся с «проблемой», а затем мы создали это «решение», перечисленное выше. Но теперь, в Android, мы хотим сделать «правильный путь». Мы хотим знать, будем ли мы сталкиваться с проблемами производительности при запросе базы данных «каждый раз». Поэтому мы решили попросить здесь предложения. Спасибо, в любом случае. – Christian
«Мы хотим знать, будем ли мы сталкиваться с проблемами производительности при каждом запросе базы данных». Поэтому мы решили попросить предложения здесь ». -- Нет, ты не сделал. Я бы хотел, чтобы ты это сделал. Вместо этого вы заявили о существовании проблемы («мы не хотим запрашивать sqlite каждый раз, когда нам нужна запись»), и вам нужна помощь в решении. Как и в случае с большинством платформ, ответ на вопрос, «если вы столкнетесь с проблемами производительности при запросе базы данных», «это зависит от запросов». Поверьте мне, только потому, что проблема с WM не означает, что одна и та же проблема существует в другом месте. Используйте Traceview. – CommonsWare