Что выбрать для хранения данных JSON или sqlite?

Question

[AlexDeww]

С сервера приходят данные в JSON формате.

Пример:

[
  {
    "currency_name": {
      "receive": "AFN",
      "send": "AED"
    },
    "name": "AFN",
    "denominations": [
      {
        "send_amount": "5",
        "receive_amount": "65",
        "order": "1"
      },
      {
        "send_amount": "10",
        "receive_amount": "130",
        "order": "2"
      },
      {
        "send_amount": "20",
        "receive_amount": "275",
        "order": "3"
      },
      {
        "send_amount": "50",
        "receive_amount": "725",
        "order": "4"
      },
      {
        "send_amount": "100",
        "receive_amount": "1500",
        "order": "5"
      },
      {
        "send_amount": "200",
        "receive_amount": "3250",
        "order": "6"
      }
    ]
  }
]

Таких файлов приходит 5 видов с разными типами данных. Объём в среднем 200 объектов на файл.
Файлы эти могут прилетать от раз день до раз в месяц.

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

Каких-то сложных выборок по этим данным нет. Лишь 1 файл может меняться на самом девайсе и отправляться обратно на сервер.

Comments

[Алексей]

Используйте Room, сильно упрощает работу с Sqlite.

[MaxLich]

Причём тут хранение в памяти? Вообще-то и бд хранит всю инфу в файлах. Просто у них своя структура, поэтому эти два утверждения бессмысленны. Но в любом случае эффективнее хранить данные в базе, а не в обычных текстовых файлах. (Хотя зависит от того, что потом нужно делать с этими данными: если активно с ними работать, делать выборки, сортировать, удалять, вставлять, то только база; если просто хранить, то можно и обычные файлы, хотя не представляю, зачем просто хранить информацию, без работы с ней.)

Answer 1

[Сергей]

про память посмотри как-нибудь в студио сколько занимает приложение памяти. объем твоих данных это мелочи.
про то как хранить.
делай все проще. если не стоит вопрос (насущный) по оптимизации - делай просто. Например часто достаточно несколько строк с gson что бы распарсить json в объекты. Для room строк побольше. Для чистого sqlite уже нужно потрудиться.

Далее. Преждевременная оптимизация это зло. Сейчас ты даже не знаешь как будет меняться твое приложение и какие узкие места в нем будут. Поэтому преждевременно что-то усложнять это стрелять в слепую.

Далее. Сто пудов, что если приложение будет полезным и будет долго жить, то будут изменения. Поэтому задача разбить приложение на более-менее независимые части. Как это сделать. Например у тебя есть часть которая отображает данные и которая предоставляет данные. И есть некое соглашение между ними. Это соглашение "оформляется" в приложении интерфейсом. Например репозиторием. Т.е. первая часть использует репозиторий (через его интерфейс) . Другая часть предоставляет реализацию репозитория. Например через парсинг текста json.
Это дает возможность при необходимости быстро заменить реализацию репозитория, что бы он брал данные из базы. Не меняя ничего другого.
примерно так)

Answer 2

[alexalexes]

В БД хранить эффективнее всего.
Извлечь потом можете хоть в JSON, хоть в XML, или отобразить в веб, как угодно.
А файлы парсить - не запросы писать. Гибкости в парсе никакой.

Comments

[AlexDeww]

А гибкость как таковая и не нужна. При помощи Gson грузим все в массив и работаем с ним(из выборок делается всего одна, по имени).

Я читал на разных сайтах про то, когда лучше использовать бд, а когда файлы.
Данные не особо динамичные, выборок сложных нет, как бы вроде и не зачем базу крутить. Но есть еще условие, это объем данных, вот с ним не понятно. Пишут если объем данных большой, то файлы для этого не очень хорошо подходят. Но что скрывается под "большой объем", 100, 200, 1000, 10000. Пять файлов по 200 объектов, это большой объем или нет. В будущем может увеличится ну максимум в 2 раза.

По большей части я склоняюсь к файлу, так как с ним проще работать. Но не могу сам себе объяснить почему.

[alexalexes]

Смотря как дальше будете использовать данные.
Если вручную изучать, как логи - это одно, а если проецировать на графики - то проблема.
Если в будущем вам понадобиться фиксировать не 3 параметра, а 5, то в базе делается alter table, а в заносящем/читающем скрипте просто добавляются еще пару параметров через запятую и все.
В случае с файлами вам придется старые файлы убирать или модифицировать их под новый синтаксис, делать в читающем скрипте адаптивность под 3 и 5 параметров, и тд.
PS: В общем, я переболел этим. Поэтому, если в среде можно поднять маломальский sql, я не упускаю возможности пользоваться этим.