SergSuper okdoky
SergSuper: Пожалуй ваш ответ наилучший, о котором думал и я. Но он (как я уже говорил) не соответствует условию "Пример эффективного представления
неограниченного в глубь дерева на основе таблиц?". Проблема вашего представления еще и в том, что разные уровни обычно имеют разные атрибуты (их имена). Вы предлагаете в одну таблицу загонять все возможные атрибуты, даже для верхних вершин?
Так, либо Вы мне показываете
переход к нижним вершинам через промежуточные , либо признаёте что были неправы и переходим к разбору Ваших дальнейших заблуждений.
Достало, распинаешься тут, а в ответ "А всё равно фигня, вот в зигзаге то у-у-у!!!"
Дак яж признал. Выделенным в вопросе осталось только слово
неограниченного . Да, добавились новые вопросы. Мы тут для того, чтобы искать как плюсы, так и минусы. Вы утверждаете, что таблицы это ВСЁ и для всего. Я, что иерархическая организация имеет не меньше плюсов. Идеально, это совместить и то и другое. При этом я утверждаю, что по быстродействию такие таблично-иерархические системы не проиграют, а только выиграют. Зигзаг, это один из примеров. Главный вопрос, кто на ком стоит? Что лучше к таблицам добавлять иерархию, или к иерархии таблицы? Пока тенденция просматривается к незаметному навязыванию иерархического (через XML, объектные модели) в надежде на дальнейшее расширение, добавление к нему преимуществ реляционного...
Интересным для развития мысли представляется статья
Крупные проблемы и текущие задачи исследований в области баз данных
автор
Пора прекратить встраивать новые конструкции в старую реляционную архитектуру . Нужно переосмыслить базовую архитектуру СУБД с целью поддержки структурированных данных; текстовых, пространственных, темпоральных и мультимедийных данных; процедурных данных, т.е. типов данных и инкапсулирующих их методов; триггеров; потоков и очередей данных как равноправных компонентов первого сорта внутри архитектуры СУБД (как на уровне интерфейсов, так и на уровне реализации).
Во многих случаях было бы лучше начать исследования с чистого листа. Пусть производители коммерческих систем продолжают следовать стратегиям расширения SQL и XML для увеличения функциональности существующих продуктов. Для исследовательского сообщества требуется выработка новой системы понятий. Участники ожидают появления нескольких прототипов новой архитектуры СУБД в течение пяти лет.
автор
Тридцать лет исследований в области языков запросов сводятся к тому, что "мы двигаемся от SQL к XQuery". В лучшем случае мы переходим от одного декларативного языка к другому, обладающему примерно тем же уровнем выразительности. Конечные пользователи не знают SQL, это язык профессиональных программистов. В родственных сообществах имеются идеи, которые могли бы повлиять на исследования в области интерфейсов к базам данных. Например, в информационно-поисковых системах в течение многих лет используются запросы по ключевым словам, в ряде областей растет популярность браузеров.
SergSuperТеперь видно, что русские могут создать свою СУБД.
Если продолжить тему данного форума интересными кажутся и такие мысли из упомянутой выше статьи.
авторЕще раз подчеркну, что в области баз данных (как и во многих других областях Computer Science)
единственным достоверным критерием истинности исследовательских результатов является успешное использование этих результатов при разработке эффективно функционирующей программной системы. В данной области системы (системы интеграции, СУБД и т.д.), как правило, бывают большими и сложными. Разработка таких систем занимает годы. На Западе (в особенности в США) на основе результатов перспективных проектов часто образуются "начинающие" (startup) компании, финансируемые различными инновационными организациями, которые доводят результаты проекта до коммерческого продукта и выходят с ним на рынок. Компании вступают в конкурентную борьбу на рынке и либо завоевывают себе право на существование (что случается крайне редко), либо приобретаются более крупными компаниями (это происходит тоже нечасто), либо (что происходит гораздо чаще) погибают.
Но даже этот не слишком надежный путь недоступен для российских исследователей. Снова причины очевидны и я не буду их разъяснять. Как нам кажется, единственным выходом в обозримом будущем является участие в движении open source. Сегодня российские разработчики активно участвуют во всех известных проектах СУБД с открытыми исходными текстами: MySQL, PostgreSQL, Interbase, Firebird. Это очень важно, поскольку проекты уже являются достаточно зрелыми, и молодые исследователи получают возможность использовать на практике имеющиеся у них знания, оставаясь на родине и одновременно сближаясь с широким международным сообществом.
Мне кажется очень важным и упоминавшийся выше проект Sedna , основанный в России, вокруг которого постепенно складывается сообщество.
