В чем недостатки текстового файла как базы данных

В чем недостатки текстового файла как базы данных

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

Здесь краткая выжимка, если вам лень читать все. Отличия хранения в файлах от баз данных:

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

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

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

Но попробуйте запустить её, скажем для файла с сотней тысяч строк – будете удивлены. Тут даже увеличение памяти может не помочь. А ведь нам еще надо сделать из этого массива другой массив, то есть разбить каждую строку по разделителю:

Следующая неожиданность – это наличие конца строки. Последний элемент массива task будет содержать спецсимволы, которые надо убрать перед началом работы:

Для того, чтобы осуществить поиск по файлу, надо будет искать в массиве соответствие. И заменить один элемент массива task не получится без ухищрений. А чтобы заменить строку, надо будет располагать всеми предыдущими данными:

Также не стоит забывать флаг LOCK_EX – чтобы никто другой не помешал нам писать в файл.

Переносимость базы и файлов

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

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

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

статьи IT, личное, базы данных, php, работа с информацией

Источник

Текстовые документы и базы данных

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

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

На следующем этапе многим приходит в голову использовать текстовый файл как некую амбарную книгу, куда легко можно заносить разнообразную «списочную» информацию, например, рецепты, телефонные номера своих знакомых, каталоги своей видеотеки, фонотеки, адреса и названия организаций и прочее. Способ представления и размещения информации в таких «амбарных» книгах обычно придумывает сам пользователь. Например, юрист может поместить в текстовый файл карточки своих клиентов с указанием фамилии, имени и отчества, адреса проживания, темы юридической консультации и других данных, например: «Иванов П.И., Тула, ул. Сафонова, д. 12, наследство», «Сидоров П.Т., Москва, ул. Тверская, д.34, кв. 25, автомобильная авария» и т.п.

Виды моделей данных

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

Различают три основных типа моделей данных: иерархическую, сетевую и реляционную. Иерархическая структура представляет собой совокупность элементов, в которой данные одного уровня подчинены данным другого уровня, а связи между элементами образуют древовидную структуру. В такой структуре исходные элементы порождают другие элементы, причем эти элементы в свою очередь порождают следующие элементы и т.д. Существенно то, что каждый порожденный элемент имеет только одного «родителя». Обратите внимание, что в иерархической структуре порождающим элементом может быть не объект сам по себе, а только конкретный экземпляр объекта. Примером иерархической базы данных может служить генеалогическое древо вашей семьи.

Реляционные базы данных

Примером реализации реляционной модели данных может быть таблица с информацией об учащихся.

Как видно из приведенного примера, реляционная таблица обладает следующими свойствами:

каждая строка таблицы — один элемент данных (сведения об одном учащемся);

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

каждый столбец имеет уникальное имя (например, в таблице нет двух столбцов Имя);

одинаковые строки в таблице не допускаются (запись о каждом учащемся делается только один раз);

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

Источник

Использование файлов вместо баз данных.

И да! Наш сайт на 100% сделан на файлах!

Файл «.dat» вместо базы данных.

«База данных» или база данных на файле?

Вообще, что такое база данных!? Это, по сути, те же файлы. Ведь физически они где-то храниться должны.

А кроме файлов, физической оболочки просто не существует! Как бы странно это ни звучало!

Существуют базы данных, которые и позиционируются, что не требуют отдельного сервера, например → SQLite

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

Я не против и не за базы данных!

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

Почему я выбрал файл вместо базы данных!?

Вам нужно перевести 10 кг груза и вы нанимаете Белаз грузоподъемность 120.000кг

Авторский сайт на файлах или на базе данных?

Мне не нравятся люди, которые нахватались верхушек и пытаются выдать себя за «гуру»! Я не ГУРУ, но я занимаюсь своим сайтом, который полностью построен на файлах и немного понимаю в файлах. Никаких предпосылок, что я собираюсь задумываться над переходом на базу данных с файлов.

И это именно то, что вы сейчас видите вокруг и давайте попробуем разобраться. «Авторский сайт на файлах» или на базе данных!?

Будут существовать два вида файлов:

Сколько строк максимально для такого файла?

И только после 500.000 строк максимальный разрешенный объем файла был пройден!

Сколько статей в день!?

Вы сможете поддерживать ритм 1 статья в день на протяжении множества лет, то чтобы превысить барьер в 500.000 строк, вам понадобится

500.000 / 365 = 1369лет

Вы сможете писать 10 статей! Здесь, я как доктор говорю, что это! невозможно для 1 человека.

Но, даже, если это чудо произойдет, то вам все равно понадобится:

500.000 / 3650 = 137лет

Зачем это я вам все рассказываю!? К тому, что файл вполне подходит для создания личного сайта.

Основные параметры базы данных в файле.

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

Всего будет два файла:

1). Где будем хранить данные о странице?

Файл базы данных(формат файла «.dat»), где будет краткая информация о странице.

Формат хранения ассоциативный массив. Первая версия была построчно

2). Где будем хранить контент?

Это мы накидали только часть того, что касается базы данных + бонус немного о страницах.

Если мы начнем говорить о движке, то это не просто много, а очень много тем. Поэтому, будет отдельная страница!

Файл + ассоциативный массив.

Вид такого массива будет, если мы его выведем через print_r :

[title] => База данных или файл данных

[description] => Хранение данных база или файл?

В чем удобства именно такого хранения данных.

Мы спокойно можем добавить любой элемент в ячейку.

Удаление ячейки происходит до банальности скучно.

Создаем уникальный «ИД»

Вы соберетесь изменить адрес данной страницы, то ваш «ИД» в ассоциативном массиве автоматически поломается!

Как решить такую проблему. Т.е. если ваша страница изменила адрес, то значит её по старому адресу нет. У меня это процесс происходит таким образом.

Копируем содержание страницы.

Удаляем страницу + автоматически удаляется ячейка в массиве.

Создаем новую страницу(вставляем скопированный контент) с новой записью в массиве.

Это для того, если массив еще не существует, т.е. не создана еще ни одна страница, то создаем пустой массив.

Ну а если массив существует, то php вовнутрь по этому условию не зайдет.

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

Процесс создания структуры массива с данными:

Записываем название массива, это переменная :

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

Вывод ячейки массива на экран с помощью print_r

Выведем первую ячейку, которая у нас получилась:

[title] => База данных или файл данных

[description] => Хранение данных база или файл?

Как будем записывать и получать данные из файла

В данном пункте, хочу обратить ваше внимание!

Что запись будет производиться «ВСЕГДА» в конец массива. Но нам нужно, чтобы свежая запись всегда была сверху. Просто, чтобы не мучаться с реверсом при выдаче, лучше помучаться с реверсом при записи!

Собака «@» нужна для того, чтобы при не существующем массиве, не выдавало ошибку.

Нам понадобится функция unserialize

Ниже. тот массив, который мы создавали. в предыдущем пункте.

$example_main_array[$page_id][title] = ‘База данных или файл данных’;

$example_main_array[$page_id][description] = ‘Хранение данных база или файл?’;

$write_for_main = @file_put_contents($dir_rotate, serialize($example_main_array));

Соберем весь код вместе:

$example_main_array[$page_id][title] = ‘База данных или файл?’;

$write_for_main = @file_put_contents($dir_rotate, serialize($example_main_array));

Картинка, либо будет загружаться новая, или же соответствует папке, в которой будет создаваться новая страница. Если вы думаете, что на каждую новую страницу будете делать новую картинку, то к 10-20 странице вам надоест! Поэтому рекомендую на каждую подтему создать картинку, и чтобы она автоматически загружалась. Чтобы не мучаться, сделаем как у меня на сайте. А уж если вы захотите. то сами измените, так, как вам надо.

Насчет ячейки авторства, если мы говорим, об авторском сайте, то это не обязательно.

Источник

Стоит ли хранить файлы в БД MySQL?

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

1. ОЗУ. Самым главным аргументом против, на мой взгляд, является тот факт, что даже когда файл нужно просто отдать пользователю (например отобразить изображение) его все равно придется загружать в ОЗУ, т.к. все данные выбранные запросом из БД загружаются в оперативную память. На момент написания данной статьи самым дорогим, после процессора, на выделенных серверах является ОЗУ. При этом я уже не говорю про обычный хостинг где в подавляющем большинстве случаев под каждый аккаунт выделяется определенное количество оперативной памяти, превышение которой приводит к «Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes)» либо к гневным письмам из саппорта.

2. Отдача файлов. Если файлы хранятся в БД, то для их отдачи в любом случае придется использовать скрипт написанный на том или ином языке, который должен сделать следующее:
2.1 Открыть новое соединение с БД, количество которых далеко не бесконечно, либо занять уже существующее но свободное соединение, что плохо по той же причине;
2.2 Запросом выбрать содержимое файла из таблицы. Тут возникает сразу 2-е проблемы:
2.2.1 Загрузка содержимого файла в ОЗУ (см. п. 1);
2.2.2 По какому параметру искать файл в БД. Логично предположить что самым быстрым будет поиск по целочисленному ID, но в таком случае в ссылке на скрипт выдачи файла так же нужно будет использовать этот ID (например: ), что в случае формирования таких ссылок вручную затруднит работу.
2.3 Отдать необходимые хидеры и содержимое файла.
И все эти шаги будут проделываться для каждого файла, а если их на странице выводиться штук 20, причем загрузка идет одновременно, то есть риск не увидеть ни одного.
Так же такой способ хранения файлов практически лишает вас следующих возможностей:
— распределить файлы по нескольким серверам и для скачки давать ссылки непосредственно на эти сервера;
— установить reverse proxy server для ускорения «медленных клиентов»
— использовать CDN.

3. Дампы. Одним из аргументов «за» часто приводят следующее: «Если мне понадобится перенести сайт на другой хостинг, то мне нужно только сделать дамп и скопировать код». Лично я не считаю этот аргумент весомым по следующим причинам:
3.1 Давайте наконец начнем писать сайты так, чтобы они быстро работали, а не только чтобы они легко переносились;
3.2 Хранение любых, а особенно бинарных файлов в БД приводит к следующему:
3.2.1 т.к. увеличивается БД то соответственно увеличивается время для создания ее дампа и его размер;
3.2.2 наличие в дампе содержимого бинарного файла очень ухудшает его читабельность, а так ж, что немаловажно, далеко не все консольные редакторы могут открыть большой дам для редактирования, например MCEDIT не может;
3.2.3 с большой вероятностью возникнут проблемы с заливкой такаих дампов:
— во-первых, это будет достаточно долгий процесс;
— во-вторых, это может оказаться достаточно сложно, особенно если сайт располагается на хостинге, который не позволяет конектиться к БД извне и не дает доступа к серверу по ssh для того, чтобы можно было воспользоваться тулзой «mysql». В этом случае Вам придется использовать скрипты вроде phpMyAdmin (хотя по своему опыту работы с ним могу с почти 100% уверенностью сказать, что через него залить дамп больших размеров 50 100 мб задача почти нереальная) или Sypex Dumper.

4. Разграничение доступа к файлам. Еще одним аргументом «за» во многих дискуссиях выступает то, что при хранении данных в БД легче организовать разграничение доступа к файлов для разных пользователей сайта. С этим аргументом я косвенно согласен, т.к. это действительно проще, но во-первых, это не перевешивает первые три пункта, а во-вторых для разграничения доступа можно использовать способы, которые я описал в этой статье.

5. Централизованное хранение. Этот пункт так же пытаются записать в актив хранения файлов в БД, обосновывая тем, что если серверов, которые работают с одними и теми же файлами много, то намного удобнее хранить их в одном месте. На мой взгляд это так же не является аргументом, т.к. даже если файлы физически будут храниться на разных серверах, то ничто не мешает их примаунтить на все сервера где они должны использоваться, при чем создав одинаковую структуру каталогов на всех серверах.

Вот вроде и все, но хочу еще раз напомнить, что я рассматривал данный вопрос со стороны программирования под web, а именно для MySQL. При этом я осознаю, что для других областей программирования и других СУБД, таких как MSSQL и Oracle все или часть моих доводов могут оказаться неверны.

Источник

Разница в хранении данных с помощью бд и с помощью текстовых файлов [закрыт]

Хотите улучшить этот вопрос? Переформулируйте вопрос так, чтобы на него можно было дать ответ, основанный на фактах и цитатах.

И теперь у меня встал вопрос в том, какие могут быть проблемы в случае, если будет использоваться именно вариант с файлами кроме того, что это просто звучит очень непрофессионально и странно?

2 ответа 2

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

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

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

Но если вы собираетесь обновлять данные частично, обновлять/читать данные одновременно в несколько потоков, делать сложные выборки по разным полям. Тогда при использовании файловой БД у вас будут мягко говоря сложности.

Я предполагаю, что скорее всего вы хранили данные в БД как-то неправильно. Не делали подходящие индексы. Не читали/обновляли данные частично (не все поля). Не хранили поля большого размера в сжатом виде. Ну и т.д.

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

С БД нужно уметь правильно работать, чтобы ощутить все преимущества «полноценной» БД.

Источник