Mysql плюсы и минусы
Автор Гимес задал вопрос в разделе PHP
Плюсы и минусы MySQL или tpl (txt)? и получил лучший ответ
Ответ от [гуру]
Принципиальные преимущества БД перед обычными текстовыми/бинарными файлами:
1) Производительность. Чтобы считать строку из обычного текстового, бинарного файла, нужно считать всё до этой строки. Чтобы изменить строку - нужно считать и переписать весь файл. Это очень медленно, если в файле сотни тысяч, миллионы, десятки миллионов строк. Файл БД же хранится в особом бинарном формате, и СУБД читает и пишет в него только то, что вы изменяете. Таким образом, размер БД мало влияет на скорость записи/редактирования/удаления конкретной строки, неважно в какой части таблицы она находится.
Можно, конечно, разбить таблицу на файлы, можно вообще каждую строку в своем файле хранить, тогда и получится что-то навроде БД (файловая система работает именно как БД, файлы читаются выборочно), но это же неудобно.
2) Доступ к текстовому файлу возможен извне напрямую, чтоб этого не было, надо редактировать .htaccess.
Внешний доступ к БД можно один раз и навсегда отключить для всего сайта.
Вроде мелочь, но тем не менее, лишние действия никогда не удобны.
3) Есть SQL, позволяющий удобно и унифицированно программным способом редактировать данные сложной структуры (с JOINами и т. д.)
Не нужно думать, как записывать эти данные в текстовый файл, не нужно затем реализовывать алгоритм парсинга этого файла.
Это очень важное преимущество. Создание парсеров - одно из самых трудоемких направлений в программировании.
4) Для БД есть удобные редакторы - phpMyAdmin, MS Access и др.
Для JSON, XML, тем более собственного текстового или бинарного их формата - их нету.
Для Excel (который НЕ является БД) удобный редактор есть, но он десктопный, а не серверный, как phpMyAdmin.
Недостатки БД:
1) Возможность SQL-инъекций, если не сделать защиту от них.
Это дело облегчают сообщения об ошибках в синтаксисе при неверных параметрах запросов, передаваемых клиентом - если опять же дыра не закрыта и клиент получает эти сообщения.
Я однажды взял и сам того не желая узнал структуру таблиц БД на одном чужом серваке, подробнее:
Вполне возможно, что при желании я мог бы и взломать ту БД.
2) Необходимость в установленной СУБД.
3) Необходимость уметь применять SQL.
4) Если данных совсем мало, то БД занимает чуть-чуть больше места, чем сырой текстовый или бинарный формат, т. к. в ней много лишнего. Убедитесь сами на примере Access.
Пароли в базе данных принято хранить зашифрованными. Расшифровываются они через mysql(AES_ENCRYPT, AES_DECRYPT). Если логины и пароли хранить в файлах, то нужно их как то шифровать.
А зачем брать из файлов, когда можно из mysql ?
Если проект на 1-100 человек, то разницы нет. как только появится нагрузка, ты упрешься в ограничения жесткого диска на количество и продолжительность io операций, и пожалеешь, что отказался от базы данных.
MySQL свои данные тоже не в воздухе хранит, а в файлах. Так что при запросе мускуль также должен обработать файл и выдать тебе ответ. И ведь не даром родилась идеология NoSQL - чтение из файла быстрее.
Так что если ты сможешь обрабатывать свои файлы оптимальнее, чем это делает мускуль, и если ты сумеешь прочувствовать разницу в скорости, тогда хранение данных в файлах будет правильным решением. В иных случаях, я бы не стал отказываться от удобства хранения данных в мускуле и не тратил бы время на строение своего велосипеда.
tpl - это шаблоны (template), вот им как раз в мускуле делать нечего.
Это все равно что сравнивать ложку с гаечным ключом.
Они для разного.
Шаблон tpl хранит разметку страниц, чтобы не делать для каждой страницы отдельный файл и при необходимости что-то изменить чтоб не редактировать вручную десятки файлов, и в нем указаны места, КУДА надо вставлять те элементы, которые на разных страницах разные, или которые запросил юзер.
А база данных хранит ТО, что надо в них вставлять.
Аналогия: tpl - это тарелки для супа, а база данных - кастрюли с супами.