Тема объединения системы управления базами данных (обычно традиционной реляционной СУБД) с файловой системой для добавления метаданных, расширенного набора атрибутов файлов, была постоянным заголовком для дискуссий на этом и других сайтах. Недавно опубликованная статья, "<a href=http://www.osrc.info/content.php?article.83>Переосознавая </a>", под заголовком "Где это хранится?" рассказывает о возможности нахождения файла без знания его точного имени или места хранения.
<br /><br />
Перевод: Роман <br />
<a href=http://www.osnews.com/story.php?news_id=9228>Оригинал </a> доступен на OSNews.com.<br />
<hr>

Основная идея
Хотя и существует множество вариаций, суть идеи в том, чтобы расширить количество и типы атрибутов файлов, чтобы позволить находить и получать доступ к файлам без знания точного пути. BeOS добавляла B-tree индексы для дополнительных атрибутов (таких как автор, название, и т.д.), тем самым делая возможным быстрый поиск, основанный на этих атрибутах. Похоже, что WinFS будет использовать для хранения и индексации атрибутов файлов Microsoft SQL server (или его версию).

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

Аргументы против

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

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

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

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

индекс статьи
страница 1 - текущая : страница без заголовка
страница 2 : страница без заголовка