Какой метод / формат для хранения данных при редком использовании?

Question

[BitRouter]

Доброго времени суток!

/*----------
немного вводной части:
--- web приложение, ООП, MVC, шаблонизатор Smarty
--- БД - MySQL
--- Apache 2.4
--- PHP 7.0
----------*/

Помогите решить затруднительную ситуацию...

Есть ряд массивов:

$continents = [];
$country = [];
$currency = [];
$lang = [];
$iso = [];
...

В общей сложности объем данных относительно не большой (1 500-2 000 строк)

Так вот! Запрашивать эти данные не будут каждый день.. Да и редакции не будут поддаваться... (возможно 1-2 раза в год).
При всем при этом в ответе от запросов к Базе вышеуказанных массивов - пользователю прилетают не все данные а при стандартной работе 1 запись, при любопытной массив с объемом до 20 значений..

Да же при такой редкой необходимости использовать данные от них многое зависит...

Варианты которые я рассматривал:
- PHP (сейчас реализовано именно путем хранения и обработки массивов в отдельном классе)
----! все работает, быстро, но как то не красиво... Почему? Все данные разложены по полочкам (основные объемы разумеется в MySQL)

- JSON - рассматривал, но 1. Все таки долго.. 2. Ну а разница - если PHP хранит точно так же и не бухтит)))

- MySQL - этот вариант мне симпатизирует эстетикой приложения)) но не более того

- выложить в config файлы Smarty (тут ни че так, только Smarty в конфиге через костыли хранит массивы,
----! так что я смотрю на это с такой стороны: зачем натягивать то что не приспособлено к этому...

- сURL - грешным делом подумал закинуть на отдельный сервер подобные данные и пущай так валяються... в любой форме и проходят обработку в т.ч. А пользователь в приложении будет точно так же конечный результат...

Answer 1

[ThunderCat]

Чет я не понял -

сейчас реализовано именно путем хранения и обработки массивов

- храните данные в пхп? В файлах? или... Не понятно кароче.

Мне видится в любом случае бд(мускуль, как наиболее распространенный, например) с отдельными таблицами на ваши массивы, пхп неплох для такого в качестве бэкенда, если нужно что-то чтобы мегабыстро работало - кеш в редис. Это достаточно стандартная связка, не вижу смысла что-либо изобртать по новой.

Answer 2

[Евгений Вольф]

SQLite3, по моему, идеальный для Вас вариант. Вернее, почти любой язык, в т.ч. PHP, + SQLite3. Его поддержка есть в PHP, Python и наверняка, почти во всём остальном.

Comments

[d'Ivan]

А какой смысл использовать ещё одну РСУБД?

[Евгений Вольф]

Роман Мирр: это не совсем "ещё одна", эта БД встроена в PHP не редко (вернее, её поддержка). Смысл, конкретно в контексте вопроса автора:
1. На маленьких объёмах данных (обычно до 200-500Мб размер БД), она работает быстрее MySQL, так как у нее нет многих механизмов, присущих MySQL. По крайней мере, на простых запросах - это так. А судя по примеру, данные так же сохранялись в JSON... что с вероятностью близкой к абсолютной - говорит о их относительной примитивности.
2. База однопоточная (или однопользовательская, как удобнее) - это так же добавляет ей скорости работы, в сравнении с MySQL на мелких объёмах данных, т.к. в вопросе автора нет ни намёка на многопользовательский/конкурентный доступ
3. Её очень просто переносить/копировать, т.к. вся база представляет из себя 1 файл
4. Она удобнее чем JSON/XML в данном случае, т.к. в ней есть SQL (со всеми вытекающими)
5. Она гораздо менее прожорлива в плане потребления памяти и процессора, в контексте данной конкретной задачи

Ну и т.д. Я бы скорее спросил "зачем из пушки по воробьям стрелять"? Если там данных до 2000 строк, если даже строка занимает 2.5Кб - это в пределах 5Мб данных. Зачем ради 5Мб без теоритической возможности потенциального роста данных и (судя по вопросу) - отсутствия как такового конкурентного доступа - тащить целый MySQL - не понятно. Особенно, если MySQL будет "притащен" только для этой конкретной задачи и больше не нужен. Можно всю SQLite-базу в оперативку загружать (с учётом её объёма) и работать оттуда, в этом случае (опять таки, в контексте вопроса) целая база будет занимать меньше, чем один только движок MySQL :)

[Евгений Вольф]

*SQlite3 доступна по умолчанию с PHP 5.3.0, подробнее

[d'Ivan]

Евгений Вольф: дело не в том, что я против использования SQLite как таковой (а я знаю что это достаточно хорошая СУБД), а что в данном случае УЖЕ используется MySQL (читая описание вводной части). И раз она таки используется, то использовать 2-ю РСУБД неразумно.

[Евгений Вольф]

Роман Мирр: да, но не совсем так. Если у кого-то "уже" топор в спине - это не повод его оттуда не вытаскивать. Иначе говоря, может ли приложение приложение описанное автором работать без MySQL - да. Может ли это приложение работать без какого-то языка-N, например, PHP - нет, и SQLite2/3, как раз таки, уже был встроен в PHP Отсюда соотв. вопрос - зачем автор вообще притащил MySQL для 1.5 таблиц объёмом <5Мб? Если бы автор уже арендовал выделенный сервер за 200$/мес. для решения этой задачи - ему бы пришлось его оплачивать и далее (ну раз он уже его арендовал)? Ну если конечно, MySQL у него не была установлена ранее, для какой-то другой задачи (но об этом ни слова не сказано, скорее даже наоборот, если в MySQL, автора вопроса, привлекает только эстетика... можно с большей вероятностью сказать, что он поставил её либо случайно, либо "прицепом", либо просто она поставилась вместе с LAMP'ом). Если MySQL уже установлен, но ещё не используется (судя по написанному автором) и больше нигде особо не нужен - снести его оттуда, ликвидировав тем самым лишнее потребление ресурсов системы и несколько лишних процессов - не составит труда. Это так же поможет нам соблюсти принцип "неразумности использования 2-й РСУБД" (хотя, я бы не стал называть SQLite - СУБД, это скорее однопоточное/однопользовательское с SQL-синтаксисом, которое используется в т.ч. в браузерах, телефонах и т.д.)

Answer 3

[tvelforce]

А если хранить в xml файле данные?

Answer 4

[Draconian]

Если у вас приложение уже работает с MySql, почему бы не создать такие справочники там? Проще будет вносить изменения и т.д.