почему-то люди, провозившиеся не один месяц с php, порой упорно не хотят вникнуть в синтаксис sql, предпочитая работать по старинке, с файлами. между тем, по мере роста базы, на сервер будет создаваться неоправданная нагрузка. использование субд может показаться ненужным и избыточным, однако сто́ит принять во внимание тот факт, что субд создаются и оптимизируются как раз для максимальной скорости работы с данными.
если работать с файлом, храня в нём достаточно объёмную таблицу (представленную в виде массива), производительность упрётся в скорость жёсткого диска и тут уже ничего нельзя будет сделать. массив перед записью требуется сеариализовать, а после, для уменьшения занимаемого места, ещё и сжать. поэтому при каждой выборке файл потребуется считать, распаковать и десериализовать, а вот уже при изменении таблицы (вставка, обновление, удаление) массив снова потребуется записать в файл. нужно ли говорить, что постоянная чтение/распаковка и упаковка/запись нагружают дисковую систему и выливаются в напрасный расход оперативной памяти и процессорного времени. также надо не забыть о том, что при открытии файла для манипуляции с записями (не выборка), его следует заблокировать для записи остальными процессами. получается, что в условную единицу времени изменение доступно только одному процессу. при разрастании таблицы с данными на процедуры работы с записями будет тратиться всё больше времени.
как вариант, можно хранить каждую запись в структуре, напоминающей файловую систему (каждой записи свой файл, однотипные записи находятся в своих каталогах). но тут уже встанет другая проблема: что делать, если записей будет тысячи? постоянно терзать файловую систему считыванием такого количества файлов не выход, поэтому само-собой напрашивается создание индексного файла, в котором будут перечислены имена всех доступных записей. в отличие от предыдущего случая, здесь при обновлении/удалении одной записи другим процессам даётся возможность работать с остальными записями (т. к. запирается лишь один файл). но взамен получили проблемы, также упирающиеся в дисковую систему и, в большей степени, в синхронизацию данных (дабы в индексном файле всегда находились корректные данные).
есть ещё один вариант: работать с двоичными данными (или для каждой записи выделять свою строку, заменяя символ перевода новой строки на что-нибудь другое). для записей выделяется файл, в который записывается строка данных. также есть второй файл — индексный, в котором записано смещение каждой записи (и может быть смещения полей, если используются значения переменной длины). осталось решить, что делать в случае, когда происходят манипуляции с записями: можно блокировать всю таблицу, а можно блокировать только одну запись (тут, правда, придётся вводить механизм отслеживания такого состояния). учитывая, что программ без ошибок не бывает, программисту, решившему использовать для хранения данных файлы, придётся потратить много времени на отладку и доводку до ума этого процесса. в итоге, он получит миниатюрную субд собственной разработки.
так нужно ли изобретать велосипед, если группа специалистов уже проделала всю эту работу и предоставила удобный и полезный инструмент, на отладку которого было затрачено сотни, а то и тысячи часов? php по скорости работы не сравнится с си, а значит все манипуляции, совершаемые скриптами, будут работать гораздо медленнее, чем в языках более низкого уровня.
синтаксис sql изначально создавался для людей, далёких от программирования. и пусть сейчас базы пополнились множеством дополнительных средств, простейшие манипуляции (выборка, вставка, обновление, удаление) выполняются очень простыми запросами, а самое главное, очень быстро (система управления базами данных берёт на себя всю работу, связанную с совместным доступом к записям).
так когда же не нужно использовать базы? в них нет смысла для небольших редкообновляемых (или больших и не обновляемых) сайтов и сервисов, использующихся довольно редко (например, гостевая книга).
днём интернета
шоколадкой для работы мозга
коробочкой ароматного чая для бодрости
продлением хостинга на +1 месяц
Автор публикации
(Оценок пока нет)
Загрузка...
