Почему MySQL использования по плоским файлам?

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

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

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

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

Подумайте о том, чтобы быстро выполнить SELECT * FROM posts WHERE MONTH (post_date) = "2010-03-10" в плоском файле и что нужно написать с нуля) чтобы добиться этого.

Кроме того, как получить все сообщения, написанные Джоном Доу (например), без сохранения всей пользовательской информации в папке Posts / ? В SQL это просто объединенный оператор выбора. С плоскими файлами вам нужно либо хранить информацию внутри фактического почтового файла, либо написать код для выполнения операций соединения и поиска самостоятельно.

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

каковы преимущества MySQL перед плоскими файлами?

Пропустите MySQL здесь - главный вопрос, который вы задаете, - «зачем вообще использовать базу данных».

Я предлагаю вам изучить производительность (операции поиска - индексы существуют не просто так) и поискать термин «условия ACID», чтобы получить хотя бы смутное представление о том, что на самом деле ДЕЛАЕТ база данных.

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

Просто пример: представьте, что у вас 1 000 000 клиентов с адресной информацией, и вам необходимо выполнить поиск и набор клиентов, которые живут в Нью-Йорке. Если вы сохранили каждого клиента в отдельном файле, вам нужно будет прочитать все 1 000 000 файлов и посмотреть, принадлежит ли клиент государству. Если вы храните все записи в одном огромном файле, вам нужно будет прочитать весь файл и выполнить итерацию, чтобы найти всех клиентов из Нью-Йорка.

В обоих случаях вы проигрываете.

В случае РСУБД, такой как MySql - вы должны использовать так называемую операцию «set» или оператор SELECT, с добавлением индексов, движок, вероятно, будет читать только на 10/20% больше данных, чем необходимо для поиска всех клиентов из Нью-Йорка.

Надеюсь, это поможет

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

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

И, наконец, использование плоских файлов, когда уже так легко использовать базы данных, - это просто взлом. Он не делает вещи «правильным способом» в том смысле, что ВСЕ ЕЩЕ используют базы данных, поэтому я бы сказал обратное: зачем использовать плоские файлы вместо MySQL? Кто-то другой приходит для поддержки вашего приложения постфактум, чтобы понять или согласиться с вашим решением использовать плоские файлы?

Нам нужно немного больше контекста.

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

Предложенное вами решение имеет два больших недостатка:

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

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

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

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

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

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