LINUX.ORG.RU

Database File System for Linux


0

0

DBFS представляет собой новую абстракцию представления файлов (прослойка между FS и пользовательскими приложениями), ключевыми моментами которой являются отсутствие привязки к физическому расположению файлов и удобство поиска нужных файлов через ассоциирование объектов ФС с ключевыми словами.

DBFS написана на языке O'Caml и использует библиотеку sqlite. В настоящее время доступны модули интеграции с KDE и Mac OS X, в roadmap у автора намечено форкнуть GNOME и возможно GTK для интеграции с DBFS. Новость взята с opennet.ru

Первоисточник новости.

>>> Подробности

★★★☆

Проверено: maxcom ()
Ответ на: комментарий от baklan

2baklan:

>Файл - это как раз папка, а не документ

AFAIK file - это подшивка, а папка - folder

Согласен, что file в компьютерном контексте несколько расплывчато, IMHO логичнее их разделить на document (или data, что вроде логичнее, потому как медиафайл мало похож на документ) и application.

Led ★★★☆☆
()
Ответ на: комментарий от anonymous

>>alias mount-старый-cd='mount -t iso9660 -r /dev/hdc /cdrom0'
>>alias mount-новый-cd='mount -t iso9660 -r /dev/hdd /cdrom1'
Ага. О чем ты ? Само понятие монтирования чуждо. А сраное 80x86 железо не имеет различных нужных возможностей позволивших бы автоматизировать монтирование и размонтирование.

anonymous
()
Ответ на: комментарий от jackill

>>Тут девочка на работе на мою реплику "Думать надо хоть чуть-чуть" >>выдала "А мне надоело думать - я за свою жизнь надумалась уже.." >>Деффке 20 лет. Остальные совсем плохие.

Немедленно вали от туда - это роботы управляемые по радио.
Их "мозг" в offline.

anonymous
()

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

Alphaer ★★
()
Ответ на: комментарий от Alphaer

> Кстати, перцы, вы смотрели, как это выглядит?

А потом суслик заворачивает все это в фольгу...

IMNSHO
()
Ответ на: комментарий от Alphaer

>делим информацию на винте на несколько категорий

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

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

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

Всё.

Теперь, скажем, будет то же самое (пусть и надстроенное пока на старой FS), но атрибуты можно будет расширять, вводя свои.

Что меняется?

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

>>Ага. Замечательно! Заменим ID3 и ему подобные потоками ФС! Всё >>хорошо... Только вот как файлы копировать? Как мне один и тот же файл >>принести на дискете (сорри, на CD - кстати, а как к этому отнесётся >>ISO9660?) к другу с BSD на RaiserFS (если он есть в BSD), к родителям >>Linux на ext3, к боссу с XP (ну хорошо, с лонгхером)?

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

anonymous
()

>DBFS представляет собой новую абстракцию представления файлов

О-о-о, БЛЯ! Абстракция на абстракцию. Это ж надо!

>(прослойка между FS и пользовательскими приложениями),

Непонятно зачем. А-а! Без этого неясно чем же лонгхорн круче xp! "Впарим" бандерлогам новую крутую фичу! Вирусов под неё понапишут, всем весело, да и железо под это дело "махнуть" не помешает. А как же?!

>ключевыми моментами которой являются отсутствие привязки к физическому расположению файлов

Вона как! А я и сейчас не в курсе в каких секторах диска у меня файл закатан.

>и удобство поиска нужных файлов

А нехрен бардак разводить, тогда и искать будет нечего. Всё по своим местам и точка. А для тупорылых работников давно есть системы документооборота и прочая куда как более удобная хренотень!

> через ассоциирование объектов ФС с ключевыми словами.

Ну да. А по запаху не пробовали?

PitStop
()
Ответ на: комментарий от PitStop

>>и удобство поиска нужных файлов

> А нехрен бардак разводить, тогда и искать будет нечего. Всё по своим местам и точка. А для тупорылых работников давно есть системы документооборота и прочая куда как более удобная хренотень!

А еще есть правила в письменном виде о хранении документов, где и как их называть -- для особо одаренных. Если такие "одаренные" имеются в конторе, то такой документ is a must.

IMNSHO
()
Ответ на: комментарий от ss

>ты работаешь в организации до 20 чел, я угадал? :-)))

не угадал, Я работал и в крупной компании где было более 100 человек.

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

Если сотрудник компании не может сделать свою работу эфективной и сидит по полчаса кнопку ищет - то такой сотрудник на фиг никому не нужен.

alphex_kaanoken ★★★
()
Ответ на: комментарий от anonymous_incognito

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

чушь! там все просто, если знаешь как :))

anonymous
()
Ответ на: комментарий от anonymous

а человеку человеково

никуда нам не деться от ассоциативной памяти

- классическая файловая система ведь то же медленно эволюционировала в сторону большей ассоциативной связанности

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

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

настоящая ассоциативная память верно приходит на замену её недоделаному предку

vm ★★
()
Ответ на: комментарий от anonymous

> чушь! там все просто, если знаешь как :))

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

anonymous_incognito ★★★★★
()
Ответ на: комментарий от KRoN73

> Сколько будет занимать сканирование хотя бы по именам каталога
> с 1 млн файлов? А в проавильно спроектированной ДБ - от долей
> секунд до секунд

"Шарик, ты болван!" (с) кот Матроскин

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

Некоторые ФС (например, Reiser) используют балансированное дерево для хранения списков имен файлов в каталоге. Как известно, для балансированного бинарного дерева время поиска (количество перебираемых узлов) примерно равно log2(N), где N - число элементов.

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

Марш читать классику, мальчик с гордым именем KRoN73

А для введения индексирования документов достаточно просто сделать в меру простой и API и реализовать его функции через СУБД - но не надо позиционировать ЭТО как файловую систему. Файловая система - способ разделения ресурса (дискового пространства), поисковая система для документов - это поисковая система для документов, и пересекаются они весьма слабо.

> Т.е. когда у каталога, скажем, может быть больше одного родителя.
> "Авианосец" может позиционироваться и в разделе "Море" и в разделе
> "Авиация". В нынешних FS это невозможно

Возможно, поверь - очень даже возможно :-)

no-dashi ★★★★★
()
Ответ на: комментарий от KRoN73

> И зачем структура каталогов нынешним ОС, если на жёстком диске они всё равно лежит одной кучей.

Ты дурак. Поиск номера inode для файла как раз производится по древовидной структуре, линеен только поиск следующего элемента пути в каталоге - но и на этом шаге у некоторых ФС используются индексы.

no-dashi ★★★★★
()
Ответ на: комментарий от alman

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

AP ★★★★★
()
Ответ на: комментарий от PitStop

>>и удобство поиска нужных файлов

>А нехрен бардак разводить, тогда и искать будет нечего. Всё по своим местам и точка. А для тупорылых работников давно есть системы документооборота и прочая куда как более удобная хренотень!

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

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

AP ★★★★★
()
Ответ на: комментарий от IMNSHO

Папки не нужны? снова паранойя? Интересно, когда понадобиться юзеру упорядачивать свои =хмм- документы: это - документы проекта "1", а это - проекта "2". Это - компромат на шефа, а это - фотки Машки голышом, Дашки нагишом, а это другой Дашки (с которой на море). Что, опять папки вспомним? Только назовем по другому?

Alphaer ★★
()
Ответ на: комментарий от Alphaer

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

AP ★★★★★
()
Ответ на: комментарий от AP

>я прекрасно представляю себе ситуацию, в которой мне нужно найти все

>документы, имеющие нечто общее, но относящиеся к разным проектам и,

>соответственно, лежащие в разных каталогах. А заодно все письма,

>относящиеся к этому "общему" и т.д. Какой бы порядок ни был, всё равно

> заколебёшься искать. Я это знаю, потому что постоянно сталкиваюсь с

>такой необходимостью.

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

Alphaer ★★
()
Ответ на: комментарий от AP

>Какая разница, как назвать? Важно, что востребована система, >позволяющая объединить данные по любому критерию (на основе тех же >метаданных).

Ага, отлично. WinFs у меня телепат и по фотке моментально отличит Машку от Дашки? Ах, нет? Значит, юзеру придется эти "метаданные" заполнять самому?

Alphaer ★★
()
Ответ на: комментарий от Alphaer

Чего-чего? Какие мягкие ссылки? Молодой человек, Вы хоть поняли, о чём мы тут беседуем, или по диагонали прочитали и встрять решили? Какой человек в своём уме будет делать софтлинки во всех каталогах по всем критериям, а?

AP ★★★★★
()
Ответ на: комментарий от Alphaer

> Значит, юзеру придется эти "метаданные" заполнять самому?

А кому? Компьютеру-телепату?

К Вашему сведению, массовое редактирование ID3-тэгов в MP3 и прочих сжатых форматах придумали не вчера и даже не позавчера. Никто не мешает перенести эту модель на файлы иных типов.

AP ★★★★★
()
Ответ на: комментарий от no-dashi

Зря, однако, на анонизмусов наезжали. Раньше их хоть фильтровать можно было, а теперь хамством (при чём с тупейшими примерами) регистрированные лезть начали... :-/

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Да не говорите. Оборзели совсем :)

AP ★★★★★
()
Ответ на: комментарий от PitStop

>А для тупорылых работников давно есть системы документооборота и прочая куда как более удобная хренотень!

Во во, докуметооборот давно придумали, и нету там каталогов, файлов --- только документы и свойтсва. Вроде бы рай для тупого пользователя не помнящего где и как сохранил документ. Но есть куча примеров, когда контора покупала систему докуметооборота за X баксов, потом была вынуждена потратить 10*X баксов на обучение сотрудников --- руководство думало --- будет охрененный рост производительности, все окупится. А сотрудники вставали в позу --- система неправильная, мы с ней работать не можем/не будем, в ней нет папок, файлов и всего прочего к чему мы привыкли.

>а человеческий разум имеет ограничение на эффективную работу не более чем с 7 вариантами выбора одновременно.

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

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

mky ★★★★★
()
Ответ на: комментарий от AP

> А кому? Компьютеру-телепату?
> К Вашему сведению, массовое редактирование ID3-тэгов в MP3
> и прочих сжатых форматах придумали не вчера и даже не
> позавчера. Никто не мешает перенести эту модель на файлы иных
> типов.

И ты думаешь, что народ в массовом порядке будет этим заниматься? Ты когда-нибудь делал в Word'е "File -> Properties"? Знаешь, что там находится? А часто туда залазишь? А можешь сказать, что там находится в последнем word-документе, который ты делал? А увлекаются ли этим твои знакомые? Ну, и?
Лично я ID3 в mp3 правил первые две недели после знакомства с winamp. Потом просто отключил их чтение и с тех пор переименовываю только сами файлы, ибо заниматься х..нёй у меня просто нет ни времени, ни желания.

yozhhh ★★★
()
Ответ на: комментарий от yozhhh

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>>Отправлять по почте ты что будешь лопату или документ (то бишь файл) >>ее содержащий ?
>Документ - да. Файл - нет.
Документ это файл.

anonymous
()
Ответ на: комментарий от yozhhh

ID3-тэги удобны при манипуляции действительно большими объёмами m3-файлами. Тому же mp3search.ru. Вот им и правда может пригодиться WinFS. Но не надо представлять её как необходимость для ВСЕХ. Большинству она на ... не сдалась. И нечего раздувать из неё принципиально новую файловую систему. Смешно просто, честное слово. Она - не более чем надстройка над ФС, реализующая функции поиска документов. И при установке ОС надо у пользователя спрашивать "Вы действительно нуждаетесь в ресурсоёмкой системе поиска документов или можете сами разобраться в структуре своих папок?". Ответ по умолчанию должен быть "НЕТ". И второе обязательное условие - возможность деинсталляции сей безумно нужной фичи в любой момент. Желательно, чтоб уже введённые пользователем метаданные при этом не терялись, а куда-нибудь экспортировались.
Вот тогда я - "за". Иначе - против.

yozhhh ★★★
()
Ответ на: комментарий от KRoN73

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

Смешной ты, честное слово. А какой смысл тогда вообще что-то обсуждать? Сесть в позу Будды и наблюдать, как M$ всех натягивает? :) Ибо сие неотвратимо, как восход солнца?
Никто и не отрицает, что кому-то сия вещь может пригодиться. Вопрос в том, насколько это явление массовое, в каких областях оно целесообразно и оправданно ли столь мощное раздувание.
Лично я не желаю быть поставленным перед жёстким выбором "либо ты ставишь себе winfs/клон, либо ты вообще не сможешь юзать новую версию ОС". А благодаря отдельным крикунам (проплаченным?) всё к тому идёт.

yozhhh ★★★
()
Ответ на: комментарий от yozhhh

>Сесть в позу Будды и наблюдать, как M$ всех натягивает? :) Ибо сие неотвратимо, как восход солнца?

Лучше спокойно наблюдать восход солнца, чем пытаться криками его остановить :)

>Лично я не желаю быть поставленным перед жёстким выбором "либо ты ставишь себе winfs/клон, либо ты вообще не сможешь юзать новую версию ОС".

Этого и не будет. Лонгхорн даже на FAT32 работает и будет работать.

>А благодаря отдельным крикунам (проплаченным?) всё к тому идёт.

Угу. Вот сейчас допечатаю и пойду бабки со счёта снимать. Прямо от Билла Гейтса.

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

>Не плачь, если уроки сделал - марш спать !

Наконец-то анонизмусы прорезались. А то аж скуно уже становилось :) Добрый вечер.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

> Угу. Вот сейчас допечатаю и пойду бабки со счёта снимать.
> Прямо от Билла Гейтса.

Тогда в чём твой интерес в отстаивании насущной необходимости winfs-клонов? Просто так, потрепаться? Давай о чём-нибудь поинтереснее поболтаем. О бабах, например.
Кстати, я так и не понял, в чём заключается твоя позиция по данному вопросу? Всемерная поддержка и продвижение? Или? Можешь кратко и чётко, тезисами очертить?

> Лучше спокойно наблюдать восход солнца, чем пытаться криками
> его остановить :)

Эк ты Билла-то. Ясно солнышко он для тебя, да? :) У меня несколько иное отношение. И даже некоторая надежда на то, что в каких-то пределах всё можно изменить. Кроме восхода солнца, само собой.

> Этого и не будет. Лонгхорн даже на FAT32 работает и будет
> работать.

Так в нём и WinFS не будет. А вот дальше-то как M$ себя поведёт? Не скажет "FAT устарела и больше не поддерживается, а WinFS показала себя с лучшей стороны, поэтому стала неотъемлемой частью". У M$ в таких вещах громадный опыт. Не подскажешь, как на Win2kSP4 корректно отключить SPC? Что-то ну никак не получается! На Win2k без SP работало... :)

yozhhh ★★★
()
Ответ на: комментарий от anonymous

>А куда делись папки, которые я брал с полки до этого?

Волшебным образом закрылись и вернулись на свою полку.

jackill ★★★★★
()
Ответ на: комментарий от geek

>Теперь понятно, почему вопросы

Только неоднократно обсужденные вопросы, которые есть в поисковиках, faq и т.п.

Ну и тупые тоже вроде "У меня fedora core на четырех дисках. Скажите, что на четвертом диске fedora core 2" Именно такой вопрос был недавно в форуме - я просто охренел от такого дибилизма.

jackill ★★★★★
()
Ответ на: комментарий от KRoN73

>Нынешние FS совершенно не занимаются никакой индексацией и т.п..

man locate

jackill ★★★★★
()
Ответ на: комментарий от yozhhh

> Не подскажешь, как на Win2kSP4 корректно отключить SPC?

Пардон, SFC. System File Check

yozhhh ★★★
()
Ответ на: комментарий от anonymous

>Немедленно вали от туда - это роботы управляемые по радио.

Вчера удалось уволиться - полтора месяца уходил, мля.

jackill ★★★★★
()
Ответ на: комментарий от AP

>А современная офисная жизнь

...протекает в 1С, структурированной БД, и папке "Мои документы" с экселем подмышкой.

jackill ★★★★★
()
Ответ на: комментарий от KRoN73

>Этого и не будет. Лонгхорн даже на FAT32 работает и будет работать.

Очень плохо. Понимать fs и работать на ней - разные вещи. fat 32 - это дыра в безопасности.

jackill ★★★★★
()
Ответ на: комментарий от jackill

>Ну и тупые тоже вроде "У меня fedora core на четырех дисках. Скажите, >что на четвертом диске fedora core 2" Именно такой вопрос был недавно в >форуме - я просто охренел от такого дибилизма.
Может я чего-то не догоняю ? А что тут тупого ?

anonymous
()
Ответ на: комментарий от anonymous

ЧИТАТЬ ВСЕМ! Развенчание глупости или почему каталоги есть шайсе...

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

>"Для вас, юноша, наверное будет откровением узнать, что в общем случае _любая_ СУБД
>для нахождения записи в _любой_ таблице будет использовать линейный full table scan
>при поиске по любому полю. И исключение из этого случая только одно - когда для поля,
>по которому производится поиск, построен индекс."


Теперь рассмотрим систему организации данных построенную на ассоциативном связывании между объектами.

простой объект в такой системе это НЕДЕЛИМАЯ ИЗ ЗА ОПРЕДЕЛЁННЫХ ЦЕЛЕЙ СУЩНОСТЬ ОБЛАДАЮЩАЯ СВОЙСТВАМИ (например объект-слово, объект-дифтонг, объект-нота, объект-3Д вертекс и т.д.) --- конечно так можно и бит информации принять объектом но именно из за целей продуктивности в сеть подвязаны более крупные объекты удовлетворяющие потребностям системы

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

ассоциативная связь между объектами - соединение, имеющее вес(силу) связи - служит для сохранения абстрактного понятия "ПОХОЖЕСТЬ" или проще сказать "АССОЦИАТИВНАЯ ДИСТАНЦИЯ" - например, похожесть между апельсином и шаром велика, а значит и вес связи между ними будет больше чем между небом и напильником.
хотя все эти объекты при желании можно привязать к классу "слово" или к классу "понятие".

теперь главное !!!
Что даёт нам всё это ?
А даёт нам это невиданную производительность за счёт высочайшей автоматизации работы управляющих алгоритмов, имеющих целевое поведение (Агенты).

Пусть мне захотелось задать такой приказ:
"Как звали того человека который присылал мне год назад описание своей работы ? Найди его контакты и сообщи ему что я бы очень хотел с ним встретиться"

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

...2. Скажем, я поставил старый почтовик и теперь делаю поиск по его БД.
Тут обнаруживается что скрипт для поиска не подходит и мне приходится е...ся с гуевыми "Ctrl+F, вырезать, вставить". Я убиваю много времени прежде чем нахожу и вытаскиваю нужного человека.

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

Итак, что мы имеем: НЕЭФФЕКТИВНОСТЬ. Огромные трудо- и время- затраты.
Кроме того, в простой ФС каждое приложение имеет свою псевдо-базу данных, что затрудняет интеграцию и стандартизацию обработки данных.


Случай второй - ООБД:
агент-поисковик находит нужный контакт и передаёт агенту-отправителю, тот, при участии агента-речевика, составляет и отправляет нужное письмо нужному адресату.
и никаких скриптов. всё что я сделал - я просто сказал задание словами :)

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

vm ★★
()

> Пусть мне захотелось задать такой приказ: "Как звали того
> человека который присылал мне год назад описание своей
> работы ? Найди его контакты и сообщи ему что я бы очень
> хотел с ним встретиться"

Так вот ВОЗЬМИ СИСТЕМУ ДОКУМЕНТООБОРОТА, и задай ЕЙ такой вопрос. Или сделай API индексации и поиска документов, прикрути его к своим программам и используй на здоровье - но еще раз говорю, не надо притягивать это за уши к операционной системе и файловой системе!

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

no-dashi ★★★★★
()
Ответ на: комментарий от KRoN73

> а теперь хамством (при чём с тупейшими примерами) регистрированные лезть начали...

Не будешь гнать пургу - будешь получать нормальные ответы

no-dashi ★★★★★
()
Ответ на: комментарий от yozhhh

> Ты когда-нибудь делал в Word'е "File -> Properties"?

Да

> Знаешь, что там находится?

Да

> А часто туда залазишь?

Да

> А можешь сказать, что там находится в последнем word-документе, который ты делал?

Да. Ещё вопросы?

AP ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.