Изобретен новый способ хранения файлов

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

Ага. И получим именно то, что имеем сейчас.

Мдя ... бардак начинается в головах ... не надо приучать людей разводить бардак ...

А почему бы не реализовать старые добрые extended attributes как в hpfs? Это же архигибкая и полезная вещь. Нет, изобретают велосипеды...

> ничего не надо удалять - надо только добавлять.

Хороший подход. Если можешь засрать - засри.

> Они не ленятся - они боятся. Их запугали: в компутерах всё не так. Имя состоит из 8 букв и ещё 3 букв разделённых точкой ;)

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

Как именно связан страх перед компьютером с нежеланием дать файлу нормальное название? Не вижу связи.

> Сделайте работу с компьютером простой! Имя (одно из) - получай список, выбирай, нах.

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

> Диалог с компутиром посредством текста или голоса и выбор из списка (результата) - несравнимо по простоте с pattern-recognition каких-то дополнительных indirections в виде пиктограмм меняющих свой look-and-feel с каждой новой версией

Именно так. Софт уже давно разрабатывается в основном в интересах маркетинга, а не конечного пользователя. Конечному пользователю всё сложнее и сложнее работать с этим нагромождением херни, которая ещё и постоянно меняется. Но разрабам насрать. Они занимаются самолюбованием.

> Для обеспечения подобной системы нужна плоская масштабируемая (B-tree-based) файловая система (типа беркли-дб), но желательно не бинарная (из соображений восстанавливаемости, поддержки итд), короче Hash/Map.

Вполне разумно, кстати. Только для самой системы предпочтительнее иерархия. Поэтому предлагаю сделать ФС для юзерских файлов объектом в общей файловой иерархии, который внешне подчиняется общим файловым правилам, а внутренне работает по своим принципам. Почему так не сделать? Зачем обязательно ВСЁ ломать?

> > Ещё лучше для каждого файла держать два ключевых слова...

> маловато будет!

Два обязательных, а необязательных - сколько угодно.

> тем более что существующие файловые системы устроены не так.

Именно так. :-) А то что inode директории содержит список inode файлов и под-директорий - это уже детели осуществления и оптимизации той словесной идеи, что я привёл.

Полезность этой приблуды очень сомнительна. 
Человек обычно запоминает не ассоциации, а действия предпринятые для
решения какого-либо вопроса и их контекст, т.е.
1)Проблема
2)Зайти в Google 
3)Ввести такой-то запрос
4)Зайти на Сайт1
5)Скачать скрипт такой-то ссылке
6)Запустить_скрипт
С поиском файлов тоже самое:
1) Если помним имя файла find ~/ -name ...
2) Если не помним cd /etc; ls; cd ...
Здесь иерархическая система выглядит наиболее логично.

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

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

> ИМХО, гораздо лучше было бы создать логическую индексируемую структуру из пользовательских файлов, с хорошшим поиском и исключениями.

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

> А почему бы не реализовать старые добрые extended attributes как в hpfs? Это же архигибкая и полезная вещь.

По той же причине, по которой расширенные атрибуты сдохли во всех известных мне инкарнациях (т.е. в HPFSе, в NTFSе, в МакОСи и в парочке линуксовых файлух). Технически, конечно не сдохли, ими просто не пользуются.

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

Блин...

Человечество да-авно изобрело способ держать в порядке большие количества документов. Спросите библиотекарей :)

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

Лично у меня проблем с поиском документов нет. И не потому, что я виртуозно пользуюсь командной строкой. Просто прежде чем сохранить документ (либо скопировать его к себе "в компьютер") я ДУМАЮ куда его поместить.

А вот если ДУМАТЬ не хочется, тогда и работать не нужно...

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

Почему сдохли EA, понятно. Мне непонятно, почему вместо того, чтобы возродить уже имеющиеся наработки, народ изобретает велосипеды типа сабжа. Сейчас, когда есть fuse, extended attributes очень бы пригодились. С этой связкой можно было бы делать кучу полезных и удобных вещей. Да и без fuse EA много бы где пригодились.

>Самый главный недостаток подхода - трудность поиска и удаления НЕНУЖНЫХ и ЗАБЫТЫХ документов.

Вот-вот. Такая прога должна иметь возможность показывать файлы в хронологическом порядке, да еще отмечая те, которые с момента помещения в ФС не были ни разу открыты. А то у меня файлы в Incoming, скачанные году так в 2001-2002 все ждут, когда я их посмотрю/сотру/перемещу куда-нибудь ;)

>Дайте мне нормальное средство текстового поиска по содержимому распространённых форматов типа pdf и можете смело отправляться нах в обнимку со своими winfs и прочей хернёй.

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

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

Так ФС и не создавались изначально для хранения файлов. Еще Профессор Луговский учил, что mc, NortonCommander и прочая нормальному пользователю не только не нужны, но и вредны. Файлами должны управлять ПРИЛОЖЕНИЯ. Вроде Amaroc, ACDSee, iTunes, WinAmp, Photoshop etc.

"... А получилось как всегда."(C) Теперь пытаются изобрести одно, УНИВЕРСАЛЬНО ПРИЛОЖЕНИЕ, которое будет управлять любыми типами файлов. Не получится у них это, имхо.

> Мне непонятно, почему вместо того, чтобы возродить уже имеющиеся наработки, народ изобретает велосипеды типа сабжа

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

> pdf это не текстовый, а бинарный формат, навроде jpg, так что за невозможность создания плюгинов, ищущих _текст_ в pdf файлах пинай свою любимую копрорацию Adobe.

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

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

> Так ФС и не создавались изначально для хранения файлов. Еще Профессор Луговский учил, что mc, NortonCommander и прочая нормальному пользователю не только не нужны, но и вредны. Файлами должны управлять ПРИЛОЖЕНИЯ. Вроде Amaroc, ACDSee, iTunes, WinAmp, Photoshop etc.

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

На днях гляну..

Ты не согласен с "профессором" луговским? Ты считаешь, что юзеру нужна работа с файлами?

> Ты не согласен с "профессором" луговским?

В чём-то согласен, в чём-то - нет.

> Ты считаешь, что юзеру нужна работа с файлами?

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

Юзер имеет право не знать про файлы и избегать непосредственной работы с ними. Ты точно так же имеешь право не знать, что в автомобиль надо заливать масло. До первой крупной проблемы с мотором. Ты можешь просто периодически обращаться в сервис, особенно когда "там что-то загорелось/запиликало/задымило, и меня это тревожит". Может быть, такая стратегия даже оправдает себя, не мне об этом судить. Но IMHO средства для работы с файлами должны иметься в наличии. Например, мне, как юзеру, они часто нужны. С их помощью я делаю свою работу с компьютером более эффективной.

много интересного рассказали тут участники форума. я однако припоминаю, что beagle -- это для linux просто более новая реинкарниция известного поисковика по файловой системе, который был удачно имплементирован в BeOS. Ничего нового к этому подходу добавлено не было. imho

если уважаемым участникам форума кажется, что я не прав, то укажите где.

>Самый главный недостаток подхода - трудность поиска и удаления НЕНУЖНЫХ и ЗАБЫТЫХ документов. А еще рай для всякой вирусоподобной дряни.

Это то-есть поиск документа со временем обращения большим 100 дней ?

А чем поиск документа в одной папке со временем обращения большим 100 дней принципиально сложнее аналогичного поиска по файловой системе?

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

Попробуйте за секунду найти все альбомы 2006 года при стандартном хранении.

> Сперва преимущество неочевидно. А теперь представьте, что при наборе тегов допущена ошибка, набито транслитом или просто на экзотическом языке.

Ээээ. Это нечестный прием. Это как если бы сказал, а представьте себе если у вас при обзывании файлов допущена ошибка и песня Битлз названа x45dsf453.mp3

Вообще странно видеть рассуждения подобного плана, если давно есть вещи типа gmail del.icio.us/google bookmarks iTunes

Стоит попользоваться ими некоторое время , чтобы понять, что к стандартному winapm'у уже очень не хочется возвращаться.

>>Такое, наверно, будет возможно только после того как станет возможным автоматический анализ контента. Когда машина будет понимать (будет обучена) какое содержание мы в этот текст вкладываем.

>Это все из области антинаучной фантастики. Либо дело очень далекого будущего. Пока люди-то не все осиливают понимание содержания текста.

Почему ? Тот-же анализ и автоматическое предложение тегов в del.icio.us работает и довольно сильно облегчает жизнь.

>Что вы думаете о перспективах этих исследований?

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

> Человечество да-авно изобрело способ держать в порядке большие количества документов. Спросите библиотекарей :)

Библиотечный каталог, если все правильно понимаю это дерево?

Дерева недостаточно. Категорически.

> анализ и автоматическое предложение тегов в del.icio.us работает и довольно сильно облегчает жизнь.

Раздача тегов по базе известных записей?

Имеет значение анализ информации. На лету. Сливаю я фотографии, и оно само отмечает "это портреты а это пейзажи, это Вася а это Маша".

Что делать с музыкой которой нет в базе? Как выполнять поиск по текстам если помнишь содержание, но не помнишь ни одного конкретного фрагмента а только можешь пересказать своими словами?

> за невозможность создания плюгинов, ищущих _текст_ в pdf файлах

4.2

Смотрим в сторону GSDL.

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

еще задолго до Ipod'ов вроде-бы фраунгофер анонсировал формат MP7.

Верно, ОДНОГО дерева недостаточно. Никто не мешает одному файлу/документу находиться в нескольких разных деревьях. Интересно, кто-нибудь напишет для fuse модуль, строящий файловую систему на основе, например, тегов mp3? Полезная вещь получилась бы.

> Смотрим в сторону GSDL.

http://ppewww.ph.gla.ac.uk/preprints/2002/14/2002-14.pdf

Это вот это? Я конечный юзер, мне надо искать текст среди большого количества pdf. Что предложите?

2 anonymous (*) (05.11.2006 13:10:39)
тогда непонятно - почему им легче и вообще надо что-то придумывать, тем более - какое-то замысловатое бессмысленное имя вместо просто слова. Придумывание - дополнительная работа. Ассоциация - она уже обязательно есть (хотя-бы одна). Имя файла - это и есть индекс (только к сожалению единственный).

>Мне нужен файл, с которым я работал вчера, работаю сегодня и буду работать завтра. Я даю ему ясное и чёткое имя. Я не хочу его искать из 1000 имён. Он мне нужен здесь и сейчас.

Один (автоматический) индекс - временной (ctime or atime). Так что последние файлы вы получите всегда. Представьте ls возвращающую по дефолту все файлы с которыми работали последнюю неделю (период можно будет легко менять).
И наоборот - помойка ненужного файлА - будет уходить из вида в историю (откуда можно опять-же всегда взять по времени).
Для человека наиболее важна проекция его временной линейки жизни - на документы/файлы - для поиска - не спорю.

>Тогда чтобы объяснить ему как пользоваться новой системой, надо
будет сказать ему примерно следующее: При сохранении файла, запомни
имя файла и ассоциацию

нет, только второе. Что и можно назвать именем файла.
Но у файла тогда может быть больше имён чем одно.
Вы не вылезаете из терминов файлосистемы, которая очень искуственна

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

> Вы не вылезаете из терминов файлосистемы, которая очень искуственна

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

кстати для многих юзеров все основные объекты работы находятся как-раз в плоской временной линейке корреспонденции лежащей в каком-нибудь аутглюке и главная ассоциативная цепочка <время работы с доком> -> <где искать> работает и так. Ещё добавление имени + возможность дать имя/индекс(ы) после модификации - и всё что надо. Но данный интерфейс работы с файлами должен работать везде - не только в одном communication-ware: от IM до браузера (всех) и просто работы с FS.

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

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

А что там, собственно придумывать? "Рецепт приготовления торта Наполеон"? Что ты предлагаешь взамен? Назвать файл "рецепт", наплодить таких штук 100, а потом изобретать запрос, чтобы найти нужный? Так тётка вместо "Наполеон" напишет случайно "Напалион" и обыщется вся потом. А с обычными файлами она сварганит папочку "Рецепты", в ней - "Торты", и туда уже будет какать. В каждой папочке файлов не так много, специальный поиск не нужен. Чётко и ясно, найти легко. А дура в обоих случаях всё проипёт, на то она и дура. И в файлах заблудится, и ассоциации перепутает. В общем, меняем шило на мыло.

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

У каждого уже существует директ-линк из моска в объекты-файлы. Теперь его надо только формализовать в виде проги чтобы истинные намерения (доступ к тому файлу) были понятны процессору

патенты же - зло; а иных целей кроме как упростить искуственно внедрённую сложность - не имеется

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

Ошибки правописания - это другая задача (для этого есть словари и проверка).

>А с обычными файлами она сварганит папочку "Рецепты", в ней - "Торты",
А если потом захочет организовать в группу все рецепты данные тётей Клавой, и незахочет делить книгу полезных советов, в которой тоже есть рецепты тортов и не только?

> Верно, ОДНОГО дерева недостаточно. Никто не мешает одному файлу/документу находиться в нескольких разных деревьях.

Несколько пересекающихся деревьев - это уже граф.

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

Если например стороить такой граф на линках (например хард), то увидев файл как узнать к каким он категориям еще относится?

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

Ты это тётке скажи. А лучше - сам попробуй как-нибудь. В google 100 резудьтатов - это 10 страниц. И все надо хоть коротко окинуть взглядом. Тётка уже через неделю пошлёт всё к чертям, нашлёт самые страшные проклятья на тупую голову разработчика и сама создаст все нужные папочки.

> А если потом захочет организовать в группу все рецепты данные тётей Клавой

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

> и незахочет делить книгу полезных советов, в которой тоже есть рецепты тортов и не только?

Не понял смысла фразы. Какую книгу? В каком виде? Если книга уже есть, то она уже поделена на главы (ты не поверишь, но это всегда делают, и даже оглавление вставляют). Зачем тётке её переделывать? Она там найдёт то, что ей надо, довольно быстро. Сто раз такое видел собственными глазами :)

> Несколько пересекающихся деревьев - это уже граф.

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

> Если например стороить такой граф на линках (например хард), то увидев файл как узнать к каким он категориям еще относится?

Проблема, видищь ли, вот в чём. Описанные тобой проблемы никак не касаются конечного пользователя с его конечной способностью к накоплению информации. Всё это может быть релевантно для больших баз, которыми пользуются большие толпы людей. Но для домашнего PC всё это - стрельба из пушки по воробьям. Лично я ещё ни разу сталкивался с ситуацией, где применение всех этих глупостей мне бы как-то помогло. Я не страдаю маниакальной тягой собирать нагромождения аудио- или видео-файлов, чтоб потом чахнуть над ними, как Кащей над златом. Нужных мне книг тоже не так много, они разложены по категориям. И у большинства неманиакальных пользователей всё точно так же. Конечно, всегда есть 1% юзеров, которым очень надо. Вот на них и работайте себе тихо, а не раздувайте из ничего проблему мирового масштаба.

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

Та же цель как мне кажется у Рейзера (http://namesys.com/whitepaper.html)
но сепараторы кажутся искуственными и внедрены из-за унаследованной необходимости иерархичности. Беркли ДБ - наше фсио (поддерживала бы ещё текстовый формат без xml - цены бы ей не было)

Например я был-бы рад хранить свои фотографии более информативно чем деревом.

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

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

А эндюзеры... Да что-ж, недавно им и куркулятора хватало... Появятся возможности - будут востребованы.

>Ты это тётке скажи. А лучше - сам попробуй как-нибудь. В google 100 резудьтатов - это 10 страниц. И все надо хоть коротко окинуть взглядом. Тётка уже через неделю пошлёт всё к чертям, нашлёт самые страшные проклятья на тупую голову разработчика и сама создаст все нужные папочки.

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

Не сталкивались с проблемой поиска/хранения телефона например зуб.врача в записной книжке (где искать: на В (врачи), З (зубной), А (Алекс) или по фамилии? Если модифицируем - обязательно забудем поменять во всех местах - если не использовать софт-линки (я в зап.книжке ставлю типа линков).

Вот как раз параграф вы в директорию не положите, а копирование - нарушит целостность данных.

>Раздача тегов по базе известных записей?

>Имеет значение анализ информации. На лету. Сливаю я фотографии, и оно само отмечает "это портреты а это пейзажи, это Вася а это Маша".

Не понимаю как вам в таком случае поможет хранение фотографий в древовидной структуре. Они сами рассортируются по папкам Маша-Петя?

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

Суть в том, что в традиционной модели ручками приходится действовать _всегда_

>А что там, собственно придумывать? "Рецепт приготовления торта Наполеон"? Что ты предлагаешь взамен? Назвать файл "рецепт", наплодить таких штук 100, а потом изобретать запрос, чтобы найти нужный? Так тётка вместо "Наполеон" напишет случайно "Напалион" и обыщется вся потом. А с обычными файлами она сварганит папочку "Рецепты", в ней - "Торты", и туда уже будет какать. В каждой папочке файлов не так много, специальный поиск не нужен. Чётко и ясно, найти легко. А дура в обоих случаях всё проипёт, на то она и дура. И в файлах заблудится, и ассоциации перепутает. В общем, меняем шило на мыло.

Проблемы начнутся когда тетке понадобится ввести категорию "Рецепты от соседки Галины Петровны"

Что вы предлагаете ? Делать подпапку в "Торты" ? А если среди рецептов от соседки бывают и супы ? Везде делать подпапки "Супы"?

А если потом понадобится найти сразу все рецепты "От соседки?" Только не надо говорить про find ж) Тетку кондратий хватит.

Сказали же вам - дерево! Но не одно а столько сколько надо.
Взять за основу одно, уже готовое и всегда сушествуюшее - иерархическое дерево каталогов в FS. И строить столько ___виртуальных___ деревьев, сколько нужно. Одним из атрибутов объекта в таком виртуальном дереве может быть file path в дереве FS.

... мда. С ходу виже проблемы и при таком подходе тоже :)
GR.