Комментарии 5
выведем список всех выкупленных билетов на заданную дату
scheduled_departure > "2017-07-18"
Подскажите пожалуйста, а подобная конструкция не отфильтрует ли билет, купленный в 2017-07-18T00:00:00.0(в таймзоне применяемой в рамках приведенного запроса) ?
Очень сомнительное решение для любой задачи. Выгоды перед обычным json-файлом - нет. Какие то хитрые выборки из справочников, требующие SQL, едва ли требуются на клиенте. Получается использование технологии ради технологии.
P.S. В SQLite нет типа данных date и такие данные хранятся как текст, поэтому scheduled_departure > "2017-07-18" работать будет (при использовании формата YYYY-MM-DD обычная сортировка строк подходит), но лучше использовать дату в UTC (int).
И да, для строковых литералов, рекомендуется использовать одинарные кавычки scheduled_departure > '2017-07-18'. Двойные - для идентификаторов, напр. имен колонок или таблиц. При компиляции есть даже специальный флаг SQLITE_DQS, запрещающий использование двойных кавычек для строк, но он по умолчанию неактивен.
Возможно. Я завершил публикацию тем что выразил в ней свое мнение.
А начал с того, что sqlite рассматривается в качестве дополнительного хранилища данных в облачных версиях Б24.
Вы предлагаете json. Наверное на небольших объемах данных действительно лучше. Только сколько будет весить такой файл на 1 млн. записей? И как быстро он будет искать нужные данные?
За подсказки по sql спасибо, не знал, учту.
По итогу, видимо не сумел популярно разъяснить главную мысль. Кейс не по тонкости и выгоду использования sqlite в отдельно взятом кейсе. Речь про то, что sqlite можно эффективно использовать как альтернативное хранилище данных на любом облачном тарифе Битрикс24
Проверил на Majestic Million CSV, который исходно весит 77мб. SQLite файл с импортированной таблицей - 72мб, json при кодировании "в лоб" [{"column1": "value1", "column2": "value2", ...}, ...] - 230мб. Однако, при передаче файла скорее всего будет использоваться gzip и тут уже не все так однозначно - sqlite ужимается до 31мб, а json до 34мб, то есть разница несущественна. В целом результат предсказуем, т.к. sqlite по умолчанию не использует архивацию данных (хотя есть расширения для этого), т.е. экономия места идет в основном за счет хранения чисел.
Насколько быстр будет поиск - зависит от того, что именно надо искать и как хранить данные. Если в json хранить строки не в виде массива, а в виде объекта, где id строки - это ключи объекта, то получение данных по id у json будет быстрее. Если надо фильтровать по текстовым полям, то sqlite может получить преимущество за счет использования индексов, но есть подводный камень: скорее всего будет использоваться один индекс из-за особенностей планировщика SQLite, т.е. при фильтрации по одной колонке с индексом SQLite будет быстрее, при участии нескольких - уже не факт.
Имхо, все справочники должны храниться на сервере и отдавать результаты по API. Вариант с загрузкой базы на клиент выглядит каким то костылем. Может в Битрикс так принято, не знаю.
Затаскиваем sqlite в облачный Битрикс24