Здравствуйте, Morgun, Вы писали:

M>Вот и хотелось бы выяснить где граница между задачами, где РСУБД применимы, а где нет. И какие подходы применимы за этой границей (кроме XML). Какие инструменты уже есть. Какие идеи есть, но еще не реализованы.
Найдеш кричи. В свое время я пытался найти сервер, принмающий запросы на SQL подобном языки, и при этом использующий, к примеру, XML файлы в качестве хранилища. Не нашел.

M>Относится. НФ выработаны для реляционной модели. Я о записях.
Собственно, тогда о чем речь? Если мы говорим о РСУБД, тогда применим весь накопленый по этому поводу материал, к примеру — приведение к нормальным формам таблиц проекта. Если мы говорим о случаях неприменимости РСУБД, то стоит задуматься о признаках таких ситуаций. Один из таких признаков — невозможность определить фиксированную структуру записи, даже с разумной долей избыточности. (В качестве примера, можно взять формат ISO-2709, более извесный как MARC формат, служащий для обмена библиографической информацией. Стандартно определены ~150 атрибутов, которые могут использоваться, плюс к этому — они могут повторяться почти произвольное число раз, плюс к этому — допускается введение в систему атрибутов, определяемых администратором, при этом необходимо иметь возможность выборки и сортировки, хотябы по некоторым из атрибутов. Создать более менее стройную систему при такой постановке задачи, хотябы с 50% избыточности я не смог, по этой причине и пришлось искать обходные пути по прикручиванию SQL сервера к этому делу.)

Здравствуйте, <Аноним>, Вы писали:

хъ

Я вот не понимаю, почему мы должны выбирать реляционные хранилища с введением "разумной доли избыточности". Почему другие типы хранилищ не могут быть эффективнее (по производительности и объему данных)? В чем секрет реляционного подхода, который дает ему неоспоримое преимущество над иерархическим, например. Теория графов, на которой основаны иерархические СУБД старее реаляционной. Подобные системы появились значительно раньше чем РСУБД, следовательно опыт должен быть больше.
Большинство понятий окружающего мира лучше всего вписываются именно в иерархическую модель, нежели реляционную. Зачем, собственно, мы тратим силы и средства для того чтобы притянуть зауши РСУБД для формализации всего этого?
Я не вижу серьезных аргументов, почему РСУБД должны быть быстрее иерархических. И там и там можно строить индексы, и там и там можно выполнять запросы. Просто иерархическая модель более гибкая чтоли. Реляционная модель, при всем моем уважении к ней, является подмножеством иерархической. Это подмножество специально было введено для упрощения работы с данными. Но ведь когда это было? На дворе 21 век!
Или я чего-то не понимаю?

Здравствуйте, Alexey Shirshov, Вы писали:

AS>Большинство понятий окружающего мира лучше всего вписываются именно в иерархическую модель, нежели реляционную. Зачем, собственно, мы тратим силы и средства для того чтобы притянуть зауши РСУБД для формализации всего этого?


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

Здравствуйте, FruT, Вы писали:

хъ

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

Реестр, например! Про устройство можно почитать в книге Рассиновича и Соломона.
Более жизненый пример, NXD — Native XML Databases. Сейчас достаточно хороших реализаций уже с десяток. Поищи в гугле.

На вскидку, exists, lore, XQuantum.

!СПАСИБО!

Здравствуйте, Alexey Shirshov, Вы писали:

хъ

AS>Реестр, например! Про устройство можно почитать в книге Рассиновича и Соломона.

Сорри, конечно же Руссиновича.

Здравствуйте, FruT, Вы писали:

AS>>Большинство понятий окружающего мира лучше всего вписываются именно в иерархическую модель, нежели реляционную. Зачем, собственно, мы тратим силы и средства для того чтобы притянуть зауши РСУБД для формализации всего этого?

Согласен на все 100%

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

Посмотрите базу данных Cache, причем именно в части глобалей и языка CacheScript.

Здравствуйте, Alexey Shirshov, Вы писали:

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

AS> В чем секрет реляционного подхода, который дает ему неоспоримое преимущество над иерархическим, например.
В универсальности.

AS> Теория графов, на которой основаны иерархические СУБД старее реаляционной. Подобные системы появились значительно раньше чем РСУБД, следовательно опыт должен быть больше.
Стех пор ка все осознали преимущества реляционного подхода, на иерархические и прочие сетевые СУБД конкретно забили, поэтому о большом опыте тут говорить не приходится.

AS>Большинство понятий окружающего мира лучше всего вписываются именно в иерархическую модель, нежели реляционную.
Отнюдь не большинство.
Весь кайф реляционного подхода именно в его универсальности, это еще дядя Кодд доказал на пальцах на своем знаменитом выступлении.

AS> Зачем, собственно, мы тратим силы и средства для того чтобы притянуть зауши РСУБД для формализации всего этого?
Затем, что РСУБД тянутся хотя бы за уши, а все остальные, чаще всего, приходится тянуть за что-то более другое.

AS>Я не вижу серьезных аргументов, почему РСУБД должны быть быстрее иерархических.
Потому что большинство проблем свести к иерархическим СУБД окажется сложнее. Там где проще с иерархией — иерархические СУБД действительно рулят, но таких задач на удивление мало.

AS> Просто иерархическая модель более гибкая чтоли.
Как раз наоборот. Из всех известных, на данный момент, моделей работы с данными самой гибкой является реляционная.

AS> На дворе 21 век!
Yes, I do, а что толку?

Здравствуйте, avbochagov, Вы писали:


A>Посмотрите базу данных Cache, причем именно в части глобалей и языка CacheScript.
А потом ужастнитесь и забудте об этом, как о страшном сне.... И главное, главное! Никогда не вспоминайте.

Здравствуйте, Barmaglot, Вы писали:

A>>Посмотрите базу данных Cache, причем именно в части глобалей и языка CacheScript.

B>А потом ужастнитесь и забудте об этом, как о страшном сне.... И главное, главное! Никогда не вспоминайте.

Интересно почему должна быть такая реакция?
Есть ли какие-нибудь аргументы? или это личная неприязнь?

Здравствуйте, Barmaglot, Вы писали:

B>Здравствуйте, Alexey Shirshov, Вы писали:

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


AS>> В чем секрет реляционного подхода, который дает ему неоспоримое преимущество над иерархическим, например.
B>В универсальности.

AS>> Теория графов, на которой основаны иерархические СУБД старее реаляционной. Подобные системы появились значительно раньше чем РСУБД, следовательно опыт должен быть больше.
B>Стех пор ка все осознали преимущества реляционного подхода, на иерархические и прочие сетевые СУБД конкретно забили, поэтому о большом опыте тут говорить не приходится.

AS>>Большинство понятий окружающего мира лучше всего вписываются именно в иерархическую модель, нежели реляционную.
B>Отнюдь не большинство.
B>Весь кайф реляционного подхода именно в его универсальности, это еще дядя Кодд доказал на пальцах на своем знаменитом выступлении.
И при этом огромные затраты на подчиненные записи. Например сточная часть документа. И тянется огромный индекс на всю таблицу.
Сделав подчиненную таблицу ввиде двухнаправленного списка избавляемся от этого недостатка.

Реляционные базы это выхолощенные иерархические, где применяется очень маленький набор подходов. Да это надежно, но не эффективно.
Но позволить расширить набор не позволяет сам доступ к базе, а не только ее структура. Много говорилось об ООП в БД , который легко стоится и на реляционных базах, но нет доступа к данным на уровне локальных БД и гибкости обсчета данных. Сейчас наблюдается уклон в этом направлении всех производителей БД.
AS>> Зачем, собственно, мы тратим силы и средства для того чтобы притянуть зауши РСУБД для формализации всего этого?
B>Затем, что РСУБД тянутся хотя бы за уши, а все остальные, чаще всего, приходится тянуть за что-то более другое.

AS>>Я не вижу серьезных аргументов, почему РСУБД должны быть быстрее иерархических.
B>Потому что большинство проблем свести к иерархическим СУБД окажется сложнее. Там где проще с иерархией — иерархические СУБД действительно рулят, но таких задач на удивление мало.

AS>> Просто иерархическая модель более гибкая чтоли.
B>Как раз наоборот. Из всех известных, на данный момент, моделей работы с данными самой гибкой является реляционная.

AS>> На дворе 21 век!
B>Yes, I do, а что толку?

Здравствуйте, Alexey Shirshov, Вы писали:

AS>Я вот не понимаю, почему мы должны выбирать реляционные хранилища с введением "разумной доли избыточности". Почему другие типы хранилищ не могут быть эффективнее (по производительности и объему данных)? В чем секрет реляционного подхода, который дает ему неоспоримое преимущество над иерархическим, например. Теория графов, на которой основаны иерархические СУБД старее реаляционной. Подобные системы появились значительно раньше чем РСУБД, следовательно опыт должен быть больше.
Проблема не в теоретическом подходе, по крайней мере для меня, а в распространенности. Сколько есть систем, поддерживающих SQL, а сколько вы знаете иерархических БД?
AS>Большинство понятий окружающего мира лучше всего вписываются именно в иерархическую модель, нежели реляционную.
Спорное утверждение, на мой взгляд.
AS>Я не вижу серьезных аргументов, почему РСУБД должны быть быстрее иерархических. И там и там можно строить индексы, и там и там можно выполнять запросы. Просто иерархическая модель более гибкая чтоли. Реляционная модель, при всем моем уважении к ней, является подмножеством иерархической. Это подмножество специально было введено для упрощения работы с данными. Но ведь когда это было? На дворе 21 век!
Еще раз повторюсь, проблема в распространенности реализаций. На сегодняшний день подавляющее большинство серверов БД — реляционные, не зависимо от того, правильно или нет это с точки зрения теории.

Здравствуйте, Serginio1, Вы писали:

B>>Весь кайф реляционного подхода именно в его универсальности, это еще дядя Кодд доказал на пальцах на своем знаменитом выступлении.
S> И при этом огромные затраты на подчиненные записи. Например сточная часть документа. И тянется огромный индекс на всю таблицу.
S> Сделав подчиненную таблицу ввиде двухнаправленного списка избавляемся от этого недостатка.
И получаем в награду кучу других. Видишь ли, любой другой сторадж встревает с тем, чтобы выполнять разные запросы. Да, запрос "дай мне строки этого документа" выполнтся немножко быстрее, из-за того, что не надо сканировать индексные страницы. Но как ты собрался выполнять запрос "найти самую раннюю дату, когда продавался заданный товар", если строка документа — это ссылка на товар, а дата есть только в самом документе?
В реляционном хранилище есть возможность индивидуального доступа к строкам документа (что и требует, собственно, наличия ссылки вверх в каждой из них), а в двусвязном списке приходится навигироваться вдоль все тех же путей.
Конечно, мы можем построить вторичный индекс и для такой схемы хранения, но преимущества подхода начнут очень-очень быстро исчезать. Фактически, это предоставление привилегированного положения одной из связей в модели. Это сулит существенное усложнение оптимизатора (по сравнению с generic-вариантом), а фактический выигрыш оказывается невелик.
S> Реляционные базы это выхолощенные иерархические, где применяется очень маленький набор подходов. Да это надежно, но не эффективно.
Нет. Мы же это уже обсуждали! От того, что ты делаешь однопользовательскую базу без транзакций на двусвязных списках, и она опережает СУБД с поддержкой ACID на некоторых видах запросов не означает, что RDBMS неэффективны. Иначе бы на www.tpc.org они бы сейчас не рулили. Хочется опровергнуть — вперед, там лежат полные описания тестов. Берите конфигурацию из тех, что подоступнее, и воспроизводите. Если удастся хотя бы 50% самого низкого перформанса получить, то уже можно присматривать роллс-ройс или астон-мартин присматривать.
S> Но позволить расширить набор не позволяет сам доступ к базе, а не только ее структура. Много говорилось об ООП в БД , который легко стоится и на реляционных базах, но нет доступа к данным на уровне локальных БД и гибкости обсчета данных. Сейчас наблюдается уклон в этом направлении всех производителей БД.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

B>>>Весь кайф реляционного подхода именно в его универсальности, это еще дядя Кодд доказал на пальцах на своем знаменитом выступлении.
S>> И при этом огромные затраты на подчиненные записи. Например сточная часть документа. И тянется огромный индекс на всю таблицу.
S>> Сделав подчиненную таблицу ввиде двухнаправленного списка избавляемся от этого недостатка.
S>И получаем в награду кучу других. Видишь ли, любой другой сторадж встревает с тем, чтобы выполнять разные запросы. Да, запрос "дай мне строки этого документа" выполнтся немножко быстрее, из-за того, что не надо сканировать индексные страницы. Но как ты собрался выполнять запрос "найти самую раннюю дату, когда продавался заданный товар", если строка документа — это ссылка на товар, а дата есть только в самом документе?
Легко. Обычно выделяется группа документо удовлетворяющие данной дате а потом идет сканирование по подчиненным записям.
S>В реляционном хранилище есть возможность индивидуального доступа к строкам документа (что и требует, собственно, наличия ссылки вверх в каждой из них), а в двусвязном списке приходится навигироваться вдоль все тех же путей.
Двух связный список находится в таблице. Тот же самый обход с чтением данных блоками.
S>Конечно, мы можем построить вторичный индекс и для такой схемы хранения, но преимущества подхода начнут очень-очень быстро исчезать. Фактически, это предоставление привилегированного положения одной из связей в модели. Это сулит существенное усложнение оптимизатора (по сравнению с generic-вариантом), а фактический выигрыш оказывается невелик.
Ну да многомиллионный индекс это не выигрыш??? Да опять же ты мыслишь оптимизатором. Интересно когда ты просто выбираешь алогритм при программировании ты оборачиваешься на оптимизатор????

S>> Реляционные базы это выхолощенные иерархические, где применяется очень маленький набор подходов. Да это надежно, но не эффективно.
S>Нет. Мы же это уже обсуждали! От того, что ты делаешь однопользовательскую базу без транзакций на двусвязных списках, и она опережает СУБД с поддержкой ACID на некоторых видах запросов не означает, что RDBMS неэффективны. Иначе бы на www.tpc.org они бы сейчас не рулили. Хочется опровергнуть — вперед, там лежат полные описания тестов. Берите конфигурацию из тех, что подоступнее, и воспроизводите. Если удастся хотя бы 50% самого низкого перформанса получить, то уже можно присматривать роллс-ройс или астон-мартин присматривать.
Берем комплексную 1С. А там связей ... Большинство работает на ДБФ+TSE. Это быстрее, хотя и не надежно. Для того, что бы сделать базу нормальной заточенной под SQL нужно потратить огромное количество времени и не факт, что удастся.
Смесь Запросов и курсоров при обсчете на сервере сразу бы решила огромное количество проблем, в том числе и применение не стандартых связей итд.

А кто мешает совершенствовать доступ к БД с транзакциями итд. То что работает в RDBMS наработано лет 20 назад. А других походов пруд пруди.
Но зачем что то совершенствовать???? Конечно легче всего скачивать данные на клиента, а потом по образу работы с локальными базами обсчитывать результаты. Будем надеятся что конкуренция сподвигнет многих на другие подходы.


S>> Но позволить расширить набор не позволяет сам доступ к базе, а не только ее структура. Много говорилось об ООП в БД , который легко стоится и на реляционных базах, но нет доступа к данным на уровне локальных БД и гибкости обсчета данных. Сейчас наблюдается уклон в этом направлении всех производителей БД.

Здравствуйте, Serginio1, Вы писали:

S>>И получаем в награду кучу других. Видишь ли, любой другой сторадж встревает с тем, чтобы выполнять разные запросы. Да, запрос "дай мне строки этого документа" выполнтся немножко быстрее, из-за того, что не надо сканировать индексные страницы. Но как ты собрался выполнять запрос "найти самую раннюю дату, когда продавался заданный товар", если строка документа — это ссылка на товар, а дата есть только в самом документе?
S> Легко. Обычно выделяется группа документо удовлетворяющие данной дате а потом идет сканирование по подчиненным записям.
Да я все понимаю. Вот только RDBMS выберет ту стратегию, которая быстрее для данного случая. Первым будет выполнен самый селективный запрос. Возможно, документы без данного товара вообще не будут сканироваться.
S> Двух связный список находится в таблице. Тот же самый обход с чтением данных блоками.
Да с этим-то я согласен. Только в середину двусвязного списка прыгнуть нельзя.
S> Ну да многомиллионный индекс это не выигрыш??? Да опять же ты мыслишь оптимизатором. Интересно когда ты просто выбираешь алогритм при программировании ты оборачиваешься на оптимизатор????
Что такое "многомиллионный индекс"???? Возьми СУБД и оцени объем индекса по инту для миллиона записей. По сравнению с исходной таблицей. При чем здесь выбор алгоритма???
S> Берем комплексную 1С. А там связей ... Большинство работает на ДБФ+TSE. Это быстрее, хотя и не надежно. Для того, что бы сделать базу нормальной заточенной под SQL нужно потратить огромное количество времени и не факт, что удастся.
Да факт, факт. Просто в свое время про...ли время на DBF. Вот теперь и показывают отвратительное масштабирование.
S> Смесь Запросов и курсоров при обсчете на сервере сразу бы решила огромное количество проблем, в том числе и применение не стандартых связей итд.
А кто мешает совершенствовать доступ к БД с транзакциями итд. То что работает в RDBMS наработано лет 20 назад. А других походов пруд пруди.
S> Но зачем что то совершенствовать???? Конечно легче всего скачивать данные на клиента, а потом по образу работы с локальными базами обсчитывать результаты. Будем надеятся что конкуренция сподвигнет многих на другие подходы.
Ты уже определись, что критикуешь. 1С — отстой, никто и не спорит. Но они не пользуются RDBMS! В этом и состоит их проблема. Поэтому критиковать RDBMS c оглядкой на 1С — ошибка.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>>>И получаем в награду кучу других. Видишь ли, любой другой сторадж встревает с тем, чтобы выполнять разные запросы. Да, запрос "дай мне строки этого документа" выполнтся немножко быстрее, из-за того, что не надо сканировать индексные страницы. Но как ты собрался выполнять запрос "найти самую раннюю дату, когда продавался заданный товар", если строка документа — это ссылка на товар, а дата есть только в самом документе?
S>> Легко. Обычно выделяется группа документо удовлетворяющие данной дате а потом идет сканирование по подчиненным записям.
S>Да я все понимаю. Вот только RDBMS выберет ту стратегию, которая быстрее для данного случая. Первым будет выполнен самый селективный запрос. Возможно, документы без данного товара вообще не будут сканироваться.
Ну если так уж хочется все обставить индесами, то двухсвяхные списки не помеха, та же таблица.
S>> Двух связный список находится в таблице. Тот же самый обход с чтением данных блоками.
S>Да с этим-то я согласен. Только в середину двусвязного списка прыгнуть нельзя.
Ну да у тебя огромные подчиненные записи. И насколько это нужно.
S>> Ну да многомиллионный индекс это не выигрыш??? Да опять же ты мыслишь оптимизатором. Интересно когда ты просто выбираешь алогритм при программировании ты оборачиваешься на оптимизатор????
S>Что такое "многомиллионный индекс"???? Возьми СУБД и оцени объем индекса по инту для миллиона записей. По сравнению с исходной таблицей. При чем здесь выбор алгоритма???
Тады два инта (и еще номер записи). Тыже на середину документа прыгать хочешь. Тут AVK недавно считал так у него трилионы записей вышли. Но обновление индекса тебя не тревожит ?????
S>> Берем комплексную 1С. А там связей ... Большинство работает на ДБФ+TSE. Это быстрее, хотя и не надежно. Для того, что бы сделать базу нормальной заточенной под SQL нужно потратить огромное количество времени и не факт, что удастся.
S>Да факт, факт. Просто в свое время про...ли время на DBF. Вот теперь и показывают отвратительное масштабирование.
S>> Смесь Запросов и курсоров при обсчете на сервере сразу бы решила огромное количество проблем, в том числе и применение не стандартых связей итд.
S> А кто мешает совершенствовать доступ к БД с транзакциями итд. То что работает в RDBMS наработано лет 20 назад. А других походов пруд пруди.
S>> Но зачем что то совершенствовать???? Конечно легче всего скачивать данные на клиента, а потом по образу работы с локальными базами обсчитывать результаты. Будем надеятся что конкуренция сподвигнет многих на другие подходы.
S>Ты уже определись, что критикуешь. 1С — отстой, никто и не спорит. Но они не пользуются RDBMS! В этом и состоит их проблема. Поэтому критиковать RDBMS c оглядкой на 1С — ошибка.
Ну насчет отстоя я бы не сказал. Вполне приличная архитектура (правда изначально была заточена на ДБФ), но и 8 ке не сильно то они и ушли.
Почему это не пользуются??? Просто беда в том, что тянут на клиента много. Вот в 8 ке трехзвенку делают. А под SQL тоже большинство работает через TSE.
Да и разговор идет о том, что RDBMS хорошо, но большее ее расширение еще лучше. Просто RDBMS это просто подвид иерархических БД.

Здравствуйте, Sinclair, Вы писали:
Да ты все за РСУБД, а посмотри сколько на XML делается и ничего ты не против.
Иерархические БД намного интереснее XML как по хранению данных так и скорости доступа.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Sinclair, Вы писали:
S> Да ты все за РСУБД, а посмотри сколько на XML делается и ничего ты не против.
В смысле? Никаких ни OLTP ни OLAP систем на XML не существует. Он прекрасен как медленный транспорт в гетерогенных средах.
S> Иерархические БД намного интереснее XML как по хранению данных так и скорости доступа.
Согласен. Но опять же, критика XML ничем не помогает в доказательстве недостатков RDBMS

Здравствуйте, Serginio1, Вы писали:
S>>Да я все понимаю. Вот только RDBMS выберет ту стратегию, которая быстрее для данного случая. Первым будет выполнен самый селективный запрос. Возможно, документы без данного товара вообще не будут сканироваться.
S> Ну если так уж хочется все обставить индесами, то двухсвяхные списки не помеха, та же таблица.
ничего не понял.
S>>Да с этим-то я согласен. Только в середину двусвязного списка прыгнуть нельзя.
S> Ну да у тебя огромные подчиненные записи. И насколько это нужно.
Я тебе привел пример. Вот такой вот возник ad-hoc запрос. И решение с двусвязным списком начинает резко сливать, поскольку другую стратегию сканирования выбрать уже нельзя.
S>>Что такое "многомиллионный индекс"???? Возьми СУБД и оцени объем индекса по инту для миллиона записей. По сравнению с исходной таблицей. При чем здесь выбор алгоритма???
S> Тады два инта (и еще номер записи). Тыже на середину документа прыгать хочешь. Тут AVK недавно считал так у него трилионы записей вышли. Но обновление индекса тебя не тревожит ?????
Да не тревожит меня обновление индекса! Эта операция вообще практически ничего не стоит! Стоят только обращения к диску. А их не более 3х на модификацию индекса. Зато потом чтений многократно меньше.
S>>Ты уже определись, что критикуешь. 1С — отстой, никто и не спорит. Но они не пользуются RDBMS! В этом и состоит их проблема. Поэтому критиковать RDBMS c оглядкой на 1С — ошибка.
S>Ну насчет отстоя я бы не сказал. Вполне приличная архитектура (правда изначально была заточена на ДБФ), но и 8 ке не сильно то они и ушли.
S> Почему это не пользуются??? Просто беда в том, что тянут на клиента много. Вот в 8 ке трехзвенку делают. А под SQL тоже большинство работает через TSE.
Вот я и говорю — отстой. Передовые ребята уже отходят от трехуровневой архитектуры, потому как она недостаточно гибкая, а 1С все еще продвигают решения в терминах файл-сервера и ISAM. Понимаешь, их проблема ровно в том же, что и у предлагаемых тобой иерархических БД. Только они засасывают справочник из DBF, а потом делают по нему фильтр, а ты предлагаешь засасывать его из двусвязного списка. Ключ к успеху — это декларативное проектирование. Именно оно позволяет серверу выбрать наилучший в данном контексте способ добиться требуемого. В отличие от императивного программирования, которое ограничивает деятельность системы жесткими рамками.
S> Да и разговор идет о том, что RDBMS хорошо, но большее ее расширение еще лучше. Просто RDBMS это просто подвид иерархических БД.
Я согласен с тем, что большее расширение RDBMS — это хорошо. Но не в сторону иерархических БД, упаси байт! Кстати, именно в эту сторону SQL-99 двигается. Ха-ха. Я посмотрю на него лет через 10.
Я кстати тебе вообще очень рекомендую книгу Гарсиа-Молина и других. Как курс по проектированию СУБД, а не БД. Там про все это очень подробно рассказано. И про XML, и про иерархии, и про структурированные файлы.

Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, Alexey Shirshov, Вы писали:

[]

А>Еще раз повторюсь, проблема в распространенности реализаций. На сегодняшний день подавляющее большинство серверов БД — реляционные, не зависимо от того, правильно или нет это с точки зрения теории.

Мы спорим о том что более распространено на данный момент? Я нет, а ты?
Я высказал мысли о том, что возможно иерархические БД (понятное дело на основе XML Infoset или другой XML data model) будут теснить реляционный как по степени распространнености, так и по другим (техническим) показателям. Для этого я не вижу никаких препядствий.