oraweb
Я не экзамены тут сдаю, а предлагаю рассмотреть возможность хранения данных не в реляционном, общепринятом виде, а в древовидном, как собственно, и устроена ФС.
Подобное хранения является упорядоченным.
По какой причине в свое время отказались от этой возможности, можно гадать, но чего не было тогда так это SQL. Остается только реализовать язык запросов для древовидной системы хранения данных.
Поэтому интересует мнение людей, которые не консервативны в своих пристрастиях и легки на подъем в усвоении новых возможностей.
Поэтому уместно отсылать к той мат. части где говорится о "дереве", а не "реалиционности".
Ну тут можно по разному ответить. Для начала деревянные БД существуют. Этот те же XMLDB с языком запросов XPath, потом M системы. Существуют и эксплуатируются.

Иерархия в дереве есть аналог навигации по указателям в обычных языках программирования. Во многих случаях поиск не нужен вовсе, если мы знаем что мы "ищем" - мы это уже нашли. p1->p2-> ...

Дерево все же не для всех задач удобно применять. Если рассмотреть дерево вс таблицы. То по сравнению с деревом более интересна сетевая модель.

ИМХО ОБД и сетевые БД по сравнению с деревянными предоставляют гораздо более интересные возможности. Особенно объектно-сетевые БД. Это те в которых модель данных представляет собой сеть (а дерево ведь частный случай сети) и в которых в узлах сети можно не только данные хранить, но и объекты с методами (интерфейсами).

Я тут в недавнем времени народу основательно поднадоел со своей собственной разработкой сетевой объектно ориентированной базой знаний. Но тут народ чиста инженерский. Им интересно только то, за что им их дядя ЗП платит. Никакой внутренней свободы - станадрт есть истина в последней инстанции.

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

ggvИ хоть хранили мы 'объекты' - в терминах LDAPv3, конечно, (inetOrgPerson там всякие), методы нам нивперлись.
что то в свое время LDAP меня на столько сильно не приколол, что сдыхался я от него весьма успешно. может и зря...

ggvМетоды у нас были в приложениях, работающих с объектами - суть есть с данными.
А вот здесь мы имеем весьма наглядное приемущество ОБД над классическими РБД - возможность полиморфного поведения объектов при наследовании интерфейсов, а не реализации. Например сервер-сайд объекты могут обмениваться друг с другом унифицированными сообщениями и реагировать на них уже согласно своей внутренней реализации. Ну типа как в смаллтоке. Для CAD|CAM систем свойство весьма интригующее. В то же время это тоже весьма интересно для серверов приложений и middle teir - business logic. То что сетевая модель позволяет более естественно работать с переменным колличеством аттрибутов у объекта по сравнению с тем же EAV - это все же вопрос удобства но не ограничений РБД. На одном этом РБД не уделать. А вот в комплексе - ИМХО вполне можно Осубд более интересную для разработчика наваять.

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