SQL БД на файлах для простого сайта

Question

[etc]

Привет! Есть простенький сайт на начальной стадии разработки, PHP 5.3, Apache 2. Первое время в БД будет храниться не более 100 записей, поэтому нужна БД на файлах с SQL синтаксисом, чтобы в будущем, когда количество записей заметно возрастет, безболезненно перейти на MySQL не меняя запросы выборки. Что посоветуете?

Answer 1

[spiff]

Как же можно такое спрашивать? www.sqlite.org/

Comments

[Александр]

+1 за это решение

Answer 2

[Сергей Береснев]

MySQL хранит записи в файлах и имеет SQL синтаксис…

Answer 3

[zapimir]

Хм, а в чем проблема сразу заюзать MySQL, чтобы не иметь в дальнейшем мороки с переездом? Хоть и то, и то на SQL, но всё равно есть свои нюансы. Ладно бы MySQL стоил каких-то дополнительных денег, а так сейчас даже на халявном хостинге он есть, не говоря о том, что платный хостинг сложно найти без MySQL.

Comments

[Виталий Желтяков]

Проблема, скорее всего, в том, что MySQL — это клиент-серверное приложение и поэтому факт соединения с БД требует достаточно много времени. Если база маленькая, то используя не клиент-сервенные способы хранения данных (файлы, SQLite) Вы получите примерно 30% прирост скорости.

[smileonl]

Проблема, скорее всего, в том, что MySQL — это клиент-серверное приложение и поэтому факт соединения с БД требует достаточно много времени. Если база маленькая, то используя не клиент-сервенные способы хранения данных (файлы, SQLite) Вы получите примерно 30% прирост скорости.

Вы это серъёзно? Что вы имеете ввиду под клиент-сервенные способы хранения данных? Откуда цифра 30 %? MySQL это по сути тежи файлы.

[Виталий Желтяков]

Да, я серьёзно.

Что бы выполнить запрос из PHP нужно сначала подключиться к серверу MySQL, что требует относительно очень много времени. А уж потом MySQL обращается к файлам БД. Сам по себе запрос происходит быстро.

При этом надо отметить, что:
— Сократить время подключения можно лишь используя постоянное подключение. Для высоконагруженных проектов этот вариант не подходит.
— Опкэшеры время подключения и запросов не сокращают.

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

Цифра 30% — это для среднестатистичекого проекта. Если используется опкэшер и ресурсов системы достаточно, то цифра ещё больше.

[WebSpider]

А как насчёт подключения через сокет?

[Виталий Желтяков]

Да, точно. Запамятовал возможность использовать сокет. Использование сокетов при подключении к MySQL приближает скорость работы с БД к скорости работы с файлами напрямую.

Answer 4

[gro]

Стандартный клинический топик.

Сначала люди, которые начинаю разбираться выдумывают какие-то решения по оптимизации, следующие из предположений основанных абсолютно ни на чём.
А потом такие же начинают разводить в камментах муть про «факт соединения с базой».

Answer 5

[Vladson]

Некоторые «решения на файлах» (SQLite правда в их число не выходит, но есть такие «движки-велосипеды» что) в конечном итоге жрут наоборот даже больше памяти и процессорного времени чем MySQL.

Comments

[Vladson]

И ещё, более того, если у вас свой сервер то можно пересобрать мускул (отрубить всё лишнее) и он вообще памяти будет жрать такой мизер что страшно становится…

Answer 6

[Александр]

Если использовать sqlite с перспективой перехода на MySQL
то продумай вопрос некой абстрактной надстройки — абстрактного класса или класса обертки, епе тебе больше нравится.

Comments

[etc]

Думал об SQLite, но читал о других решениях, поэтому решил спроить об оптимальном. Да, конечно, прослойка однозначно будет в виде класса. Все-таки не зря читаю книгу по проектированию :)

[Андрей Ширяев]

А в чем смысл этих извращений в будущем хотите себе работы добавить? Берите сразу MySQL да и все, а если это визитка на 5 страниц, то можно вообще хранить как массив сериализованный или прямо в html без php.

Answer 7

[Кирилл Мамаев]

Кстати, а какая СУБД не хранит данные в файлах? И уж какое «ПО», называющее себя СУБД, не имеет SQL-синтаксиса?

В любом случае, что-то, что представляет какой либо интерфейс, к какому либо механизму — требует накладных расходов. Не проще ли вообще отказаться от SQL и работать напрямую с файлами? Но тут тоже можно найти кучу узких мест в производительности.

Мой совет — работать сразу с MySQL. Если честно не понимаю, почему это только запланировано, а не используется сразу. Неужели при сотне записей вы испытываете проблемы с производительностью если пойдете классическим путем, неужели надо исхитряться и отыгрывать не тривиальными способами эти 30%?