Обойтись без MySql?

База данных != MySQL, есть и более миниатюрные релизации. Все сводится к тому, что скрипт будет делать с этими данными, если нужны представления в различных срезах и т.п., то придется, по сути, городить свою реализацию подобия БД, что нафиг не нужно.

Для такого размера данных я бы использовал исключительно MySQL. Во-первых, быстрее, во-вторых, просто удобнее. Да и мало ли, что впереди ждёт сайт, может быть, придётся админку под него делать али ещё что полезное. Поэтому, всё же не стоит лениться и переведите данные в мускул.

Да, это я понимаю. В том то и дело что ничего кроме выборки по ключу не надо. То есть структура данных такая: [key] -> [value].

Пхпшный массив отлично подходит для быстрой выборки по ключу, быстрее не надо.

Поэтому и думаю хранить все как сериализованный массив в файле. Но не уверен что прокатит)

ppch, подумайте о способах сохранения целостности файлов, коллизиях и накладных расходах.

Уже не так просто получается. Может, лучше готовый интерфейс?

Возможно и можно. Но лучще sqlite тогда уже.

целостность файлов не критична, это просто viewer, эталон данных хранится в другом месте.

коллизий быть не может доступ только на чтение.

накладные расходы вижу в необходимости серверу поднимать в память весь массив с диска при каждом обращении - можно порешать кэшированием в памяти, если будет критично.

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

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

---------- Добавлено 10.10.2014 в 08:43 ----------

sqlite надо чтобы на хостинге был, и там тоже как-бы файл базы данных формируется, который надо хранить и заботится о его целостности.

учитывая что данных мало и запросы простые... не вижу особого смысла заморачиваться.

в инете где-то была да CMS примерно в 100кб, которая работает без базы, и все информация хранится в текстовых файлах.

Не лучшая идея. Посчитайте сколько займет места сериализованный массив: исходные данные + накладные расходы на сериализацию. И этот массив при каждом чихе(обращении к сайту) нужно будет полностью считывать в память, чтобы достать одну страничку.

Про модификацию данных молчу - придется делать какую-то админку и проверку на целостность файла при сохранении, а то место закончится - и оп-с сайта уже нет.

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

Определить в какой файл лезть: берете один или два симола от функции md5($key).

Стремный подход... но для гавников на фрихостах может и покатит. :)

Уже посчитал - максимум 100 мегабайт с учетом расходов на сериализацию.

Расходы на закачку в память массива можно легко решить memcache'м.

Только чтение, модификации нет.

Подход хороший, думал об этом, спасибо.

Вам нужно key -> value.

Так возьмите простенькие типа Redis, Memcached и их подобных - быстрые удобные и подходит под Ваши запросы.

Можно спокойно и обойтись без базы.

Но например скорость чтения и записи будет крайней мала.