файловая система

[Sergei I. Gorelkin]

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

Вот это как раз пример того, что изначально поиск не предполагался. Тут особой науки не нужно: достаточно папки а-ля "сканировал не для себя" и линка на нее с рабочего стола. Уже достаточно, чтобы почти сразу попасть на нужный уровень иерархии. Дальше в конкретном случае со сканированными картинками несколько хуже - как из них извлечь информацию, кроме как ocr на лету? Но для облегчения нашей жизни все оболочки умеют показывать превьюшки

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

Достаточно вместо OC подставить "Explorer" или "Konqueror", и получим почти действительность. Разница только в том, что работает на ring 3, а не на ring 0. Службы индексации тоже есть, правда, о степени их совершенства разговор отдельный.

p.s. Постоянно оказываюсь на стороне пессимистов... Но это все от лени

[Рождённый_в_СССР]

Sergei I. Gorelkin
на рабочем столе у меня нет не одного ярлыка, я там люблю окна растягивать... потому что иначе через месяц там будет такая же свалка как в Program Files у всех добросовестных ламеров, только в стиле сканировал не для себя, скачал для пети, нашёл компрамат на женю, написал программу кате и так далее...

Достаточно вместо OC подставить "Explorer" или "Konqueror"

я говорю избавится от путей, вы отвечаете поставь программу которая кроме путей ничего не знает.

[Alexander]

я говорю избавится от путей

Ну не обязатльно от путей совсем избавляться, достаточно чтобы
они не были ОСНОВОЙ системы хранения. А как один из вариантов
представления - запросто.

[Alexander]

А вообще существующая система иерархии, именования это
действительно источник тормозов и беспорядка.

[ev]

неужели вы некогда не искали что нить вроде eMule Incoming среди кучи папок?... неужели вы не рылись в деревьях иерархии по всему кому в поисках где же там хелп, который шёл с пхп?... не пытались найти старую программу с названием, которое давно забыто?

нет

всё таки попробуйте на секунду представить как бы было без путей, без папок и файлов...

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

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

[Рождённый_в_СССР]

будет как в корзине

ничего не в корзине, возьмите любую БД, к примеру там нет явного пути например на этот пост и сразу в корне...
нужно просто по другому относится к информации... не как к деревьям... человек не может в уме держать дерево - это сложно сразу в уме собрать дерево, при чем где каждые две ветки в корне отличаются друг от друга, а если их не две а больше? и в каждой ветке свои ветки, а там ещё? и при этом это все постоянно изменяется?
это сложно...
теперь посмотрим на пример БД этого форума: нам нужен мой пост: он в таблице постов, простая логика... узнать где именно мои - сделать запрос выбрать все посты с таким то ником из всех постов... затем посмотрим по дате и так далее... как видите такой поиск более интелектуален, чем если бы я всё подряд индексировал или упаси господь переберал все посты... помойму это больше напоминает человеческое мышление, хотябы потому что мы отделили суть информации от её значимости, и можем оперировать предложениями типа : выбрать из всех никнеймов, 10 (первых) тех в алфавитном порядке, кто оставил пост последним в такой то теме. Причем это 1 составная команда SQL, которую можно описать буквально в 1 строчку. Теперь представьте себе команду подобного плана в locate или find например (полная аналогия): найти размеры 10-ти (первых по алфавиту) текстовых файлов в порядке уменьшения размера, которые создала такая то программа за вчера.
Причем если SQL-код сильно напоминает вышеописанную разговорную речь, то о синтаксисе find такое скажет тока робокоп
о скорости поиска во втором случае я вообще промолчу

[Sergei I. Gorelkin]

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

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

[Alexander]

Сам поиск идёт с применением строк - тормоза.

[Рождённый_в_СССР]

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

не совсем. select определяет важный момент - тот ключ, который приходит человеку на ум сразу, а это вовсе не то, где находится папка с моей программой и на каком она там диске... это уже после рассуждений мозг начинает это делать (В ОБРАТНОМ ПОРЯДКЕ!) а вообще посмотрите на ход мыслей ! начало то... нужна моя программа на Паскале! а не папка где она валяется... эту необходимость папки вам навязали, потому что иначе вся иерархия развалиться в хаос... далее мы вспоминаем аха - писали её вчера или что-то на каком то модуле остановилось всё... сразу среди этого селекта ищем нужные строки а не сначала копаемся в дисках и папках а потом тока думаем а чего это и где я такое нашёл... и почему здесь такая куча файлов tmp. bin и прочее, где среди всего этого моя программка? а... это модуль, программа как то не так называлась

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

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

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

[AbakAngelSoft]

В одном из проектов в котором я участвую - отлично удается сращивать иерархию и таблицы - максимально эффективным и с точки зрения пользователя и с точки зрения скорости методом.
Проект - система автоматизации документооборота.
Пример:
Существует таблица в базе данных "счета". Каждый счет имеет поля "дата выставления", "менеджер", "клиент" и т.д.
Для пользователя все представлено в виде классических папок и файлов, но конкретный счет (от 1.01.2009 выставленный Васей Пупкиным компании Рога и копыта) можно найти например так:
1. Документы\1.01.2009\Счет №29086
2. Менеджеры\Вася Пупкин\Выставленные счета\Счет №29086
3. Клиенты\Рога и Копыта\Ожидаемые оплаты\Счет №29086
и еще в десятке мест - пользователи в восторге - во всяком случае те с которыми общался я.
Вася пупкин создает счет в своей папке, автоматически ставится дата, из выпадающего списка он выбирает клиента, заполняет счет - и все! этот "файл" сразу "появляется" во всех местах где его догадаются искать.

Добавлено спустя 9 минут 5 секунд:
PS Могу помочь в этом вопросе, в меру сил и возможностей.

[Slavikk]

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

[AlexVinS]

Пока не появилась некоторая принципиально новая модель хранения информации, если отказываться от понятия "файл", возможно, стоит посмотреть в сторону ООБД.

[AlexVinS]

Другой вариант: хранилище соответствующее ACID (атомарность, непротиворечивость, изоляция, долговечность) но без объектов, отношений итп. Пример berkeleyDB.

[Gendos]

Всем суток добрых!

Перечитал весь топик. Нет единого мнения может всё таки начнем с того что будет в итоге и начнем ТЗ с конца.
И будем обсуждать +\- (не занимался я этим никогда, но почему бы не начать)

Пока читал мое видение ФС, а почему бы не 3D-ФС. Координатные составляющие определяют начало и конец данных. Уровни по оси Z определяют тип данных и их атрибуты (системные, пользовательськие)- да хоть пусть считается каталогом.

Вобще будет ли понятие каталог, фаил, разумна ли эта идея про трехмерность (многомерность). БД - надежность? не создадим ли дополнительную глючность. Насколько ФС будет динамична в размерностях (или же фиксировать). Идеальна ли она будет по скорости в таком случае?
(не пинать клавами и не хлестать мышками) - я все же пионер в этом, а при правильных замечаниях гляди рожу что нибудь интересное в своём буйном воображении.
ОБСУДИМ!

МИР-1 и МИР-2 вообще был сплош и рядом на матрицах (а ведь работал и неплохо - карты серьёзные обрабатывал)

[Gendos]

Как говорится - погугли.
Перечитал много обзоров, тестов, исследований.
Есть что то уже подобное не ФС, но можно рассматривать в качестве основы MOLAP (как абстракцию).
К реализации конечно приступать рановато, я как N дней fpc исследую.
Товарищи гуру - замечания, вопросы, спустите меня на землю!