Как лучше сделать сайт: на базах данных или на файлах?

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

Напомним, что каких-то лет 20-30 назад сайты зачастую выполнялись "по-старинке", т.е. на файлах. При этом каждая вебстраница представляла собой не просто информацию, динамически выбранную из базы данных, а файл, например, имеющий расширение html (или htm, если говорить о совсем старых сайтах). При этом сообщения пользователей, их личные кабинеты, реквизиты и пр. также хранились в файлах. Равно как и контент, все содержимое сайта, например, рисунки, скрипты и прочие ресурсы.

В чем преимущество использования баз данных в интернет-проектах?

Перечислим основные преимущества:

1. Удобство использования, простота реализации интерфейсов для записи и чтения данных;
2. Если проект сравнительно небольшой, то база данных вполне может храниться в одном файле, что может облегчить ее обслуживание (лишь в некоторых случаях);
3. Удобство и легкость реализации архитектуры;
4. Не требуется высокая квалификация разработчиков;
5. Качественная разработка на базах данных несравненно дешевле, чем на файлах.

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

В чем преимущество использования обычных файлов в интернет-проектах?

Стоит понимать, что база данных - это тоже файл, один или несколько (может быть и сложная иерархическая структура). Поэтому здесь, применительно к теме обсуждения, под термином "файл" понимается "обычный файл", т.е. текстовый, имеющий формат html или php. Можно перечислить такие преимущества:

1. Легкость вхождения. Т.е. начинающему программисту легче делать сайт на основе файлов, чем вникать в базы данных, особенности SQL-запросов, тонкости реализации архитектуры. Правда это - только на первом этапе.
2. Наглядность. В условном смысле "как слышится, так и пишется". Файлы, каталоги можно увидеть непосредственно в файловом менеджере. Потому что информация хранится в отдельных файлах, а не в некоей безликой "базе данных". Можно взять и посмотреть каждый отдельный файл.
3. В случае поломок, как правило, могут быть испорчены только один или несколько файлов. Восстанавливать потребуется только их.
4. Нет необходимости в отдельном сервере для баз данных.
5. Высокая скорость работы сайта.
6. Легкость переносимости сайта и/или восстановления.
7. Невысокая подверженность уязвимостям.

Обсуждение

На самом деле, есть и еще некоторые преимущества каждого из подходов. Выше перечислены лишь основные. Безусловно, большинство сайтов, фигурирующих ныне в интернете, выполнены с использованием тех или иных баз данных. Какие-то из них зарекомендовали себя хорошо, какие-то - не очень. Есть и платные, и бесплатные разновидности. Попробуем пройтись по отдельным преимуществам.

1. Базы данных: удобство использования, простота реализации интерфейсов для записи и чтения данных

Для управления базами данных существует специальный язык запросов. Новичкам он может показаться "сложным". Однако, это только на первый взгляд. После примерно месяца даже не слишком интенсивного изучения любой, кто мало-мальски способен программировать, легко освоит основные нюансы работы с базами данных. Ибо ничего особо сложного там нет. Следует лишь усвоить основные ключевые слова, порядок построения запросов. Ну, и позаботиться о безопасности, т.е. чтобы не внести уязвимости при запросах.

При использовании баз данных совершенно нет необходимости разрабатывать собственный интерфейс для записи/чтения данных; нет необходимости продумывать формат файлов, их внутреннюю структуру. Нет необходимости в управлении файловыми структурами и каталогами. Все это (и не только это) выполнит движок соответствующей базы данных. Т.е. эти операции реализованы "под капотом", рядовому разработчику вовсе необязательно в это вникать. Разработчику остается только грамотно сформулировать запрос к базе данных, ну, и реализовать его отправку, обработать результат. Все остальное выполнит сама база данных. Она сама сделает запись данных, сама реализует, в случае необходимости, структурирование информации в виде отдельных файлов.

А вот при работе с файлами разработчику придется реализовывать это все САМОМУ. Придется продумывать и делать каждую мелочь, плоть до названия и расширений файлов, мест их расположения. Придется продумывать интерфейс доступа к ним. Придется решать (довольно сложные) вопросы, как быть в случае высокой нагрузки на сайт. Т.е. придется САМОСТОЯТЕЛЬНО реализовывать очереди запросов, проверку и обработку ошибок записи, продумывать файловую архитектуру и ряд других вещей. Т.е. потребуется реализовывать все то, что уже реализовали разработчики баз данных.

Разработчику сайта, выполненному на файлах, в будущем следует быть готовым к тому, чтобы реализовать СВОЮ систему управления данными.

Если проект небольшой, не обладает высокой загрузкой - это еще ладно. Но, по мере его усложнения то и дело придется предпринимать все новые и новые решения, направленные на обеспечение эффективной и безопасной работы с информацией, представленной в виде файлов. Впрочем, если решения, реализованные разработчиками, являются эффективными и правильными, то ничего страшного в расширении проекта нет. Но, это - "если". В противоположном случае придется переписывать проект заново. 

2. Базы данных: если проект сравнительно небольшой, то база данных вполне может храниться в одном файле, что может облегчить ее обслуживание (лишь в некоторых случаях)

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

3. Базы данных: Удобство и легкость реализации архитектуры

Имеется в виду "техническая" ("низкоуровневая") архитектура. Например, пусть имеется база данных с полями: "Имя", "Возраст", "Пол", "Доход", "Адрес". Также имеется еще одна база данных со следующими полями: "Адрес", "Тип населенного пункта", "Погодные условия".

Например, требуется узнать, в каких населенных пунктах проживают люди, имеющие определенные доходы. Пусть будет такой запрос.

При использовании баз данных все просто: нужно лишь сформулировать соответствующие запросы на управление этими двумя базами данных. Т.е. сделать выборки. Эти запросы займут, от силы, несколько строчек.

А вот при работе с файлами придется, мягко скажем, повозиться. Это придется прочитать первый файл, извлечь оттуда все строчки, значения доходов в которых подпадают под заданные условия. Одно дело, если всего строчек сравнительно немного, например, не более 100...300 тысяч. Тогда можно сразу извлечь все строчки и поместить их массив или структуру. И работать с ними дальше.

Если же строчек очень много, то придется реализовывать их обработку по частям. Придется также учесть, что подобных запросов может быть очень много (в секунду). При этом возникнет необходимость реализации очередей запросов. Например, путем помещения их в... отдельный файл. Для работы с ним также придется создавать отдельный интерфейс. Это, конечно, вполне реализуемо и будет работать. Но - придется проектировать и реализовывать самостоятельно.

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

Тогда как при использовании баз данных разработчик даже и не будет подозревать о 70-80% всего перечисленного. Имеется в виду, типичный разработчик, не высококвалифицированный. Он просто сделает соответствующие запросы на выборки, да и все.

4. Базы данных: не требуется высокая квалификация разработчиков

Этот пункт логически вытекает из всех предыдущих. В самом деле.

Более того, то и дело встречаются вакансии, требующие от кандидатов умения реализаций запросов к базам данных (например, для осуществления тех или иных выборок), но где НЕ ИДЕТ речь даже о проверке результатов запроса, тем более, не идет речь о потоках, очередях и пр. Потому что, в самом деле, базовая работа с базами данных настолько несложная, что не требует каких-то особых познаний от разработчика.

Так вот, именно этим, на наш взгляд, и объясняется тот факт, что подавляющее большинство интернет-ресурсов и, соответственно, разработчиков используют базы данных. После того, как они появились, в том числе, в бесплатном виде. Это - последние лет 20-30.

5. Базы данных: качественная разработка на базах данных несравненно дешевле, чем на файлах

Естественно, если не требуется высокий профессионализм разработчиков, то и работа их стоит дешевле. Ну, а еще и наличие многочисленных (на любой вкус) фреймворков, конструкторов сайтов и иных высокоуровневых решений превращает разработку сайтов и вовсе в достаточно несложное дело. Именно поэтому в последнее время наблюдается устойчивая тенденция снижения зарплат интернет-разработчиков. Наряду с резким ростом их числа. Потому что любой, окончивший 2-3 месячные курсы по программированию, уже называет себя "разработчиком" и заявляет о своей принадлежности к IT.

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

Сейчас же, начиная примерно с 2020 г., ситуация кардинально иная. Сейчас, за исключением редких случаев, НЕ ТРЕБУЕТСЯ реализация вручную того, что уже давно реализовано, написано кем-то. И предоставляется в бесплатном доступе. Сейчас, зачастую, требуется лишь состыковать одно готовое решение с другим. Т.е. ситуация в разработке сайтов стала напоминать, например, сантехнику. Когда слесарю не требуется изготавливать детали (например, втулки, краны, вентили, фильтры и пр.) самостоятельно. Ему лишь требуется грамотно установить/заменить готовые, заводские детали на другие, тоже готовые.

Таким образом, резюмируя, можно сказать так. Базы данных - это удобный, легко масштабируемый, легкий для использования (по сравнению с файлами) инструмент. Использование которого в разработке на первом этапе является гораздо более дешевым. Который позволяет вести разработку специалистам не слишком-то высокого уровня. Что весьма удобно при МАССОВОЙ разработке сайтов, т.е. информационного ширпотреба. И, пожалуй, иных серьезных достоинств у баз данных не было и нет.

1. Файлы: легкость вхождения. Т.е. начинающему программисту легче делать сайт на основе файлов, чем вникать в базы данных, особенности SQL-запросов, тонкости реализации архитектуры. Правда это - только на первом этапе

В самом деле, если говорить о начальных операциях (типа - записать данные в файл, прочитать данные из файла, создать файл), то, безусловно, работа с файлами гораздо проще, чем с базами данных. И это - ровно до тех пор, пока не потребуется реализовывать, скажем так, специальные возможности. Например, сделать запись в файл с определенного места и так, чтобы имеющиеся ниже данные сохранились. Или когда приходится учитывать НЕатомарность языков программирования.

Или когда требуется реализовать мало-мальски сложную архитектуру данных. Вот тут начинающий разработчик не сделает практически ничего. А если и сделает (вдруг), то, с высокой долей вероятности, созданное им решение приведет, мягко скажем, к проблемам в работе сайта. Потому что, еще раз, ему придется учитывать очень многочисленный ряд нюансов, которые осуществляются в базах данных "под капотом", т.е. неявно. Например, такие, особенности кодировки данных, последовательность доступа к файлам, отличие символов от байтов, а то и бинарные нюансы. И это все при том, что в ряде языков веб-программирования, например, в PHP, присутствуют еще и недокументированные особенности. Например, плохое качество блокировки файлов, нюансы с кодировкой заглавной буквы И, проблемы с поиском подстрок и многое другое. Более того, разработчик сайтов на файлах (без баз данных) должен знать и нюансы быстродействия разных конструкций языка, например, циклов.

Т.е. разработчику сайтов на файлах мало знать интерфейс доступа к ним. От него потребуется также знать просто кучу разных нюансов и тонкостей. В том числе, и обусловленных некорректной работой языков программирования.

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

2. Файлы: наглядность. В условном смысле "как слышится, так и пишется". Файлы, каталоги можно увидеть непосредственно в файловом менеджере. Потому что информация хранится в отдельных файлах, а не в некоей безликой "базе данных". Можно взять и посмотреть каждый отдельный файл

Это - безусловно. Получив доступ на сервер то ли по протоколу SSH, то ли из какого-нибудь файлового менеджера (типа общеизвестной FileZilla), можно непосредственно видеть файловую структуру. Можно очень легко, за доли секунды, удалить, добавить или заменить тот или иной файл.

Тогда как с базами данные все несколько сложнее. Там такие операции возможны лишь с таблицами баз данных. А также - с полями в отдельных таблицах. 

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

А это - запросы, а не непосредственное ви́дение структуры файлов и каталогов. Более того. Какой-нибудь подозрительный файл можно просто взять и открыть. И изучить на предмет опасного содержимого, например. Тогда как с записями баз/таблиц данных такое не пройдет. Ибо для того, чтобы сделать запрос на выявление опасного содержимого, придется ЗНАТЬ, как оно, такое содержимое, выглядит.

Правда, когда файлов - очень много, то какой же из них является подозрительным, как определить? Однако, это - уже второй вопрос. Самое главное, что файлы таки дают такую техническую возможность. А насчет баз данных - ее дают, отчасти, только те, которые содержат информацию в незашифрованном (текстовом) виде. Например, Sqlite.

3. Файлы: в случае поломок, как правило, могут быть испорчены только один или несколько файлов. Восстанавливать потребуется только их

Это - несомненный плюс файловых сайтов. Их восстановление-ремонт, как правило, НЕ затрагивают всю структуру данных. Если что-то испорчено, то исправлять требуется, как правило, только это. Т.е. это - сильное преимущество использования файлов по сравнению с базами данных в вебразработке. 

4. Файлы: нет необходимости в отдельном сервере для баз данных

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

5. Файлы: высокая скорость работы сайта

Также сильное преимущество. В силу только что сказанного. Однако, лишь в том случае, если сайт на файлах сделан правильно, с учетом многих тонкостей, см. п.1. Т.е. когда речь идет о грамотной разработке.

Т.е. если требуется высокая скорость работы сайта, то отказ от баз данных - это очевидный выбор.

6. Файлы: легкость переносимости сайта и/или восстановления

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

Тогда как сделать копию базы данных себе на локальный компьютер - это более сложная задача. Здесь могут возникнуть даже такие нюансы, как, например, несоответствие системы управления базами данных на сервере и на локальном компьютере. Да, можно, конечно, установить на свой компьютер ту систему, которая установлена на сервере... Но, что, если сайтов - много, хостингов - тоже много? И на каждом, в целом. может быть установлена своя система управления базами данных. В таком случае придется устанавливать себе целый набор таких систем. Ну, или использовать средства контейнеризации (типа Docker). Т.е. это - такое себе "развлечение".

Также можно вспомнить о размерах баз данных, которые, для мало-мальски серьезных сайтов, являются довольно большими. Если делать себе локальные копии время от времени, то придется скачивать себе ВСЮ базу данных. Все те многочисленные гигабайты информации.

Тогда как с файлами все гораздо проще и быстрее. Ведь можно скачивать только те файлы, которые необходимо.

7. Файлы: невысокая подверженность уязвимостям

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

Это, пожалуй, самое важное преимущество использования файлов для разработки сайтов в противовес базам данных. Разумеется, речь идет о грамотной разработке, в противоположном случае все преимущество файлов будет сведено на нет. Будем считать, что и в случае баз данных, и в случае использования файлов сайт выполнен "идеально", т.е. разработчики не сделали явных ошибок.

Если говорить сайтах, выполненных на файлах, то там имеются звенья, могущие допустить появление уязвимостей:

1. Сам сайт, выполненный на том или языке программирования. Например, на PHP, java или вовсе на С/С++.
2. Среда языка программирования. Например, интерпретатор РНР.
3. Сервер, на котором все это работает.  Например, Apache или Nginx.
4.  Операционная система компьютера-сервера, на котором все это выполняется. Например, Linux или Windows.

В случае же баз данных к этим четырем звеньям добавляется еще следующие:

5. Система  управления базами данных (СУБД).
6. Компьютер, на котором установлена и выполняется эта система. А также - операционная система этого компьютера. Зачастую, на хостингах в интернете сервер баз данных представляет собой отдельный компьютер, не тот, на котором установлен Apache или Nginx.

Особую важность представляет собой п.5. Дело в том, что СУБД вполне могут содержать уязвимости. Это не домыслы, а исторический факт. Например, в языке РНР применяются функции по работе с базами данных. Их немало и они начинаются с символов mysql_. Эти функции в свое время применялись на ВСЕХ сайтах, которые были выполнены на РНР  и где применялись базы данных.

Однако, потом оказалось, что все эти функции являются уязвимыми.

В результате, в языке PHP появились аналогичные функции, начинающиеся с mysqli_. А старые были объявлены устаревшими (deprecated).

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

Что же касается уязвимостей в других звеньях, например, в Linux или Apache, то их, во-первых, гораздо сложнее проэксплуатировать. Если для эксплуатации уязвимостей в СУБД (было) достаточно сравнительно невысокой квалификации хакера (это и объясняет массовость взломов сайтов), то чтобы взломать Linux или Apache - это надо иметь на несколько порядков выше уровень знаний и умений. И людей, способных на такое, не столь уж много в мире.

Выводы

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

Стоит лишь понимать, к каким издержкам, как краткосрочным, долгосрочным, а также неожиданным, которые могут возникнуть в совершенно любое время (см. п.6, 7) готовы владельцы сайтов. Разработчикам-то, понятно, проще и быстрее сделать реализацию на базах данных. При том, что ни один разработчик не даст стопроцентную гарантию, что его программный продукт будет полностью неуязвимым. Если уж такие гарантии не дают даже крупные корпорации, типа Microsoft или Google, то что же хотеть от разработчиков более низкого уровня. 

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

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