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

Обновлено: 07.07.2024

Споры по данной теме мне приходилось наблюдать на нескольких форумах, порой даже по нескольку раз. В основном эти темы касались хранения изображений, реже текстовых файлов. Сам я отношусь к противникам данного метода и в статье попытаюсь привести обоснованные доказательства того, что хранить файлы в БД неудобно и негативно влияет на скорость работы системы в целом. Поскольку в основном я работаю с 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 (например: <img src='./getimage.php?id=1111'>), что в случае формирования таких ссылок вручную затруднит работу.
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 все или часть моих доводов могут оказаться неверны.

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

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

Необходимо самому реализовывать способы работы с информацией в файлах – например, поиск значения.
При больших объемах файлов (данных) приходится усовершенствовать эти способы, так как если объем файла превышает 10 тысяч строк, то уже начинаются проблемы с копированием его в массив/память.
Систему с БД (sql) можно легко перенести на другой хостинг/сервер – только не забыть про строку подключения. А вот в файлах даже относительные пути на другом сервере могут внезапно начать вести себя по-другому.
Есть разные мелочи, например, необходимо не забывать про блокировку файла при записи или убирать концы строк при сравнении значений (а также добавлять их при записи).

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

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

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

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

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

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

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

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

Еще немного

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

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

Принципиальные преимущества БД перед обычными текстовыми/бинарными файлами:

1) Производительность. Чтобы считать строку из обычного текстового, бинарного файла, нужно считать всё до этой строки. Чтобы изменить строку - нужно считать и переписать весь файл. Это очень медленно, если в файле сотни тысяч, миллионы, десятки миллионов строк. Файл БД же хранится в особом бинарном формате, и СУБД читает и пишет в него только то, что вы изменяете. Таким образом, размер БД мало влияет на скорость записи/редактирования/удаления конкретной строки, неважно в какой части таблицы она находится.
Можно, конечно, разбить таблицу на файлы, можно вообще каждую строку в своем файле хранить, тогда и получится что-то навроде БД (файловая система работает именно как БД, файлы читаются выборочно), но это же неудобно.

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

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

4) Для БД есть удобные редакторы - phpMyAdmin, MS Access и др.
Для JSON, XML, тем более собственного текстового или бинарного их формата - их нету.
Для Excel (который НЕ является БД) удобный редактор есть, но он десктопный, а не серверный, как phpMyAdmin.

2) Необходимость в установленной СУБД.

3) Необходимость уметь применять SQL.

4) Если данных совсем мало, то БД занимает чуть-чуть больше места, чем сырой текстовый или бинарный формат, т. к. в ней много лишнего. Убедитесь сами на примере Access.

Пароли в базе данных принято хранить зашифрованными. Расшифровываются они через mysql(AES_ENCRYPT, AES_DECRYPT). Если логины и пароли хранить в файлах, то нужно их как то шифровать.
А зачем брать из файлов, когда можно из mysql ? Madfish Просветленный (24057) Если из файловой системы брать файлы, то это очень не удобно получится. Куча файлов и папок. А в базе данных все представления абстрактные. Это намного удобнее. Лол что? AES - симметричный алгоритм, имея ключ (он как правило в той же бд, или в коде где-то), ты прост восстановишь все пароли. у нормальных людей пароли нигде не хранятся, только результат хеш-функции, через которую был пропущен пароль (ну например sha-224). Madfish Просветленный (24057) Значит мы не нормальные :) то-есть если проект маленький (чисто информационный) без регистрации пользователей, то и база данных не нужна? Madfish Просветленный (24057) Смотря какое количество информации там. Если проект на 1-100 человек, то разницы нет. как только появится нагрузка, ты упрешься в ограничения жесткого диска на количество и продолжительность io операций, и пожалеешь, что отказался от базы данных. Что такое "ограничения жесткого диска на количество io операций"?
Каких именно операций? Pleiades Taurus Гуру (2556) io - input/output. корочи, ты ограничен в количестве попыток чтения/записи за единицу времени. база данных - те же файлики, только работает она с ними поэффективнее. и чем больше данных, тем эффективнее бд с ними работает по сравнению с твоим fopen fseek . и что там дальше.

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

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

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

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

Только отличие файла от базы данных в способе обработки !
Кроме того!

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

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

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

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

Но зато! Я 5 лет пользуюсь файлом в качестве базы данных. Одна строка - одна статья (формат файла ".dat").

Скоро - может даже сегодня, напишу(давно надо было сделать это), как можно хранить данные вашего сайта даже и без SQLite - это вообще самый, самый, самый простой способ! И если бы данный способ, как-то меня не устраивал, то я давно бы искал бы альтернативу!

Единственное -может, если ход дойдет, то для будущих статей буду изучать "SQLite"(но это не точно!) .

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

Базы данных придумали не просто так! И для большого проекта - скорее всего нужно использовать базу данных вместо файла.

Но когда вы собираетесь делать авторский сайт, блог, то база данных - это просто. ну не знаю.

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

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

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

Просто. частенько вижу в интернете категорические высказывания типа: "Сайт на файлах отстой и т.д. и т.п." - важно не на чём ваш сайт построен! А какой контент ! Это самое главное, что вам следует запомнить!

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

Предположим , что вы хотите сделать свой собственный авторский сайт(это моя история).

Естественно -самое простое - хранение данных в файле!

Давайте попробуем посчитать на пальцах емкость файла - ведь нам нужно знать, сколько статей вы сможете написать , прежде, чем файл станет неподъемным!

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

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

А контент будет храниться в отдельных файлах - одна статья - один файл.

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

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

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

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

Предположим, что вы зададите себе план - 1 статья в день!

Поверьте мне на слово - что это не так просто сделать, как кажется! Насколько я упертый, даже я не смог этого сделать, за все время существования данного проекта, всего дней : - 2185 дней .
И если мы разделим количество статей, на данный момент 916 , на выше приведенное количество дней, то получим:
4 статьи в 10 дней. (0.41922196796339)
P.S. если интересно смотри счетчик сколько статей в день php

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

500.000 / 365 = 1369лет

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

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

500.000 / 3650 = 137лет

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

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

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

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

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

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

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

Сейчас - думаю нет необходимости останавливаться на этом подробно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как и что, будем хранить данные в файле .dat

После того, как мы получили уникальный "ИД" - $page_id, который и будет главной ячейкой для страницы:

Если вы обратите внимание на ниже идущую первую строчку, то вы должны спросить - зачем там условие!

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

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

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

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

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

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

Вторым элементов с троке идет уникальный ид ячейки - это переменная(т.е. таким образом переменной можно присвоить любое значение.) :

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

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

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

$example_main_array[$page_id][author] = 'Марат';// Если это будет авторский блог , то данная ячейка не нужна!

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

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

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

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

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

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

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

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

Из нашего будущего файла "$dir_rotate" - путь естественно должен быть на сервере

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

Переменная "$reverse_ok" - нам понадобится ниже, - надеюсь по названию понятно почему!? Чтобы развернуть массив.

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

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

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

Далее проверяем был ли перевернут массив $reverse_ok, если да, то возвращаем в нормальное направление

Нам нужна строка, поэтому превратим массив в строку - serialize

$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));

Форма ввода для записи в файл .dat

Нам нужна форма для записи данных в базу в файле .dat, какие данные будем записывать!?

Дату - создания записи - date('d.m.Y').

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

Далее два поля, изменим название ячеек в соответствии с "POST", чтобы потом не путаться! - поскольку они обязательны required, то никаеи условия можно не писать.

$example_main_array[$page_id][title_for_main] = $_POST['title_for_main'];
$example_main_array[$page_id][description_for_main] = $_POST['description_for_main'];

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

Две ячейки и [url] - на них остановимся на отдельных страницах, потому, что в двух словах тут не получится.

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

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

(а) текстового редактора как инструмента манипулирования текстами;
(б) группы текстовых файлов (базы данных) как объекта обработки.

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

Например, врач может поместить в файл карточки своих пациентов, с указанием фамилии, пола, даты рождения или возраста, диагноза и других данных, например: "Ветров С.И. /м/ЗЗ лет/Анемия", "Савченко Т. /ж/12.10.80/Ларингит" и т.п.

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

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

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

Конкретный диагноз должен обозначаться совершенно одинаково во всех карточках БД. Например, можно условиться, что сочетание 02 всегда обозначает анемию и только анемию, 08 - ларингит и только ларингит. Такое сочетание называется кодом диагноза.

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

Если усложнить правила игры и соответственно - программу, можно научить машину отождествлять "Анемия" и "Анем.", но это другая тема, которой мы коснемся далее.

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

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

Теперь мы можем уточнить определение информационной системы.

ИС - это совокупность тем или иным способом структурированных данных (базы данных) и комплекса аппаратно-программных средств для хранения данных и манипулирования ими.

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

Читайте также: