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

хъ

S>И получаем в награду кучу других. Видишь ли, любой другой сторадж встревает с тем, чтобы выполнять разные запросы.

С чего то?

S>Да, запрос "дай мне строки этого документа" выполнтся немножко быстрее, из-за того, что не надо сканировать индексные страницы. Но как ты собрался выполнять запрос "найти самую раннюю дату, когда продавался заданный товар", если строка документа — это ссылка на товар, а дата есть только в самом документе?

Не понял. Если ты клонишь к тому, что индексы могут существовать только в реляционной модели — твои заблуждения не знают границ!

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

Ты про sequental acess и random access? Опять не понимаю, почему random access связывается у тебя исключительно с РБД.

S>Конечно, мы можем построить вторичный индекс и для такой схемы хранения, но преимущества подхода начнут очень-очень быстро исчезать.

Почему?

S>Фактически, это предоставление привилегированного положения одной из связей в модели. Это сулит существенное усложнение оптимизатора (по сравнению с generic-вариантом), а фактический выигрыш оказывается невелик.

Откуда такие предположения?

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

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

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

[]

S>В смысле? Никаких ни OLTP ни OLAP систем на XML не существует. Он прекрасен как медленный транспорт в гетерогенных средах.

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

xml как транспорт конечно прекрасен, но его возможности значительно превосходят данный аспект.

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

хъ

S>Я тебе привел пример. Вот такой вот возник ad-hoc запрос. И решение с двусвязным списком начинает резко сливать, поскольку другую стратегию сканирования выбрать уже нельзя.

Я не понимаю, откуда взялся список?

хъ

S>Я согласен с тем, что большее расширение RDBMS — это хорошо. Но не в сторону иерархических БД, упаси байт!

Ну никто не настаивает. Продолжай изучение РСУБД.

S> Кстати, именно в эту сторону SQL-99 двигается. Ха-ха. Я посмотрю на него лет через 10.

А я на тебя.

S>Я кстати тебе вообще очень рекомендую книгу Гарсиа-Молина и других.

Кстати, не очень книжка. Даже с точки зрения реляционной теории, не говоря уж о объектных СУБД.

S>Как курс по проектированию СУБД, а не БД. Там про все это очень подробно рассказано. И про XML, и про иерархии, и про структурированные файлы.



Если тебе хватило про xml того, что там написано на 3-х страничках, тогда для меня твои доводы перестают быть удивительными.

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

Что бы закончить эту тему. То отличие иерархических БД (в моем понимании) отличается только различием связей. Если в обычных РБД это первичный индекс то в иерархических РБД это пряммая ссылка на запись и соответственно применение различных структур. Но при добавлении уникального индекса она лекго превращается в обычную РБД когда нужен обмен между базами или репликация. Но при работе в своей базе скорость получения ссыочной записи возрастает. Так же как и в обычном программировании для связей по некоторому ID использутся хэш таблицы и Б+ деревья, но ссылки на объек идут через указатель. Представь какие были бы тормоза если вместо ссылки на объект записывался его ID в хэш таблице?????

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

S> Что бы закончить эту тему. То отличие иерархических БД (в моем понимании) отличается только различием связей.
Ок. Вот только кажется мне, что это называется не иерархическими, а сетевыми БД (в первых основная концепция — не указатель, а принадлежность кортежа другому). Ну, да это вопрос терминологический.
В таком случае фактически ты предлагаешь хранить такой специальный тип данных "RID", который будет указывать прямо на физический локейшн кортежа? В каких-то случаях это может привести к повышению производительности. В некоторых — к снижению.
Интересно, почему же вместо него используются FK? Надо покопать в эту сторону.

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

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

S>> Что бы закончить эту тему. То отличие иерархических БД (в моем понимании) отличается только различием связей.
S>Ок. Вот только кажется мне, что это называется не иерархическими, а сетевыми БД (в первых основная концепция — не указатель, а принадлежность кортежа другому). Ну, да это вопрос терминологический.
S>В таком случае фактически ты предлагаешь хранить такой специальный тип данных "RID", который будет указывать прямо на физический локейшн кортежа? В каких-то случаях это может привести к повышению производительности. В некоторых — к снижению.
S>Интересно, почему же вместо него используются FK? Надо покопать в эту сторону.
Это связано прежде всего с обменом. FK для ссылочной целостности и его можно строить и на RID. Но никто же не мешает для каждой записи иметь уникальный ключ аналог PK как для репликации. Вот у меня хренова куча разнородных баз и для обмена существуют уникальные ключи состоящие из двух полей автоинкремента и ID базы. (вернее все в одну строку).
Но на RID можно делать более хитрые связи и структуры таблиц и при этом полностью соответствовать классическим РБД. Но это уже в компетенции разработчиков.

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

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

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

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

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

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

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

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

S> И при этом огромные затраты на подчиненные записи. Например сточная часть документа. И тянется огромный индекс на всю таблицу.
Какие затраты? Какой индекс? Ничего никуда не тянется...

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

S> Реляционные базы это выхолощенные иерархические, где применяется очень маленький набор подходов. Да это надежно, но не эффективно.
Это очень эффективно, потому как быстро, просто и надежно.

S>>И получаем в награду кучу других. Видишь ли, любой другой сторадж встревает с тем, чтобы выполнять разные запросы.
AS>С чего то?
Судьба такой.

AS>Не понял. Если ты клонишь к тому, что индексы могут существовать только в реляционной модели — твои заблуждения не знают границ!
Нет, это ты сам придумал..
Что тебе даст индекс в иерархической системе? В идеальном случае опять получится та же реляционка, только с дополнительным геморроем по обеспечению иерархии. Так зачем платить больше?

AS>Ты про sequental acess и random access? Опять не понимаю, почему random access связывается у тебя исключительно с РБД.
Ну сделай эффективный sequental acess по иерархической БД, а я на тебя посмотрю.

AS>Почему?
Потому что в итоге ты получишь ту же реляционку.

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

AS>xml как транспорт конечно прекрасен, но его возможности значительно превосходят данный аспект.
Ага, только к OLTP и OLAP его возможности имеют очень мало отношения.

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

S> Но при этом джойны уверяю вырастут в разы.
Заблуждаешься. Ты даже не представляешь, какой выигрыш дает при join'е оптимизация с учетом B tree индекса и твоя схема по сравнению с этим — просто детский лепет.

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

AS>Я не понимаю, откуда взялся список?
Читай внимательно.

AS>Кстати, не очень книжка. Даже с точки зрения реляционной теории, не говоря уж о объектных СУБД.
А читать пробовал?

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

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

S>> Но при этом джойны уверяю вырастут в разы.
B>Заблуждаешься. Ты даже не представляешь, какой выигрыш дает при join'е оптимизация с учетом B tree индекса и твоя схема по сравнению с этим — просто детский лепет.
Раскажи поподробнее об оптимизации с учетом B+ дерева, вместо прямой ссылки. Вот программисты тупые держат всегда прямые ссылки на объект (хотя это и виртуальный адрес), вместо Хэш таблицы или Б+ дерева в памяти????

Здравствуйте, Serginio1, Вы писали:
S> Вот только назови эти случаи. Сам по себе RID уникален и должен прописываться вместе с записью как PK это нужно для апдейтов при корректировке записи клиентом. Для совмещения с другими базами и репликации придется делать еще поле и индекс. Да при этом вставка и модификация несколько (а может и нет, т.к. на RID не нужно строить индекс, а при изменении не надо лезть в индекс для поиска записи). Но при этом джойны уверяю вырастут в разы.
Ну, во-первых, размер RID как минимум в 4 раза больше стандартного INT, который используется для FK. Насчет индексов ты не прав — без них ты не обеспечишь ссылочную целостность. Что ты будешь делать, когда удаляется запись? Правильно, для всех FK, которые ссылаются на ее отношение, нужно проверить exists(select * from referrer where FK = @PK). Так что индекс — нужен. Если ты имел в виду индекс по PK, который требовался для обеспечения уникальности — тут да, есть некоторая экономия. Выращивание джойнов в разы — это самообман. Проценты — это более точная оценка. А для кластерного индекса (который, обыкновенно, и делается для PK) разница будет еще меньше. Если ты в этом не уверен, то я тебе намекну — стоимость join зависит только от количества сканируемых страниц. Вот и оцени разницу для clustered int PK и для 16-byte RID. Никаких разов, уверяю тебя, ты даже в некластерном варианте не получишь.

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

S>Здравствуйте, Serginio1, Вы писали:
S>> Вот только назови эти случаи. Сам по себе RID уникален и должен прописываться вместе с записью как PK это нужно для апдейтов при корректировке записи клиентом. Для совмещения с другими базами и репликации придется делать еще поле и индекс. Да при этом вставка и модификация несколько (а может и нет, т.к. на RID не нужно строить индекс, а при изменении не надо лезть в индекс для поиска записи). Но при этом джойны уверяю вырастут в разы.
S>Ну, во-первых, размер RID как минимум в 4 раза больше стандартного INT, который используется для FK.
Зачем ему быть таким же большим, если это только номер записи???? Являющийся и уникальным ID.

S> Насчет индексов ты не прав — без них ты не обеспечишь ссылочную целостность. Что ты будешь делать, когда удаляется запись? Правильно, для всех FK, которые ссылаются на ее отношение, нужно проверить exists(select * from referrer where FK = @PK). Так что индекс — нужен. Если ты имел в виду индекс по PK, который требовался для обеспечения уникальности — тут да, есть некоторая экономия. Выращивание джойнов в разы — это самообман. Проценты — это более точная оценка.
Почему то я тебе не верю. Или опыт у меня маленький. Проигрыш Б+ деревьев по отношению Хэш таблицы в 4 раза, а разница хэш таблиц по сравнению с массивом это уже десятки раз. При этом учитывая что данные либо кэшируются а памяти (либо кэшируются на файловом уровне либо как в SQL на уровне страниц впринципе механизм одинаковый) и при работе с кэшированными данными разница весьма ощутима, даже не с кэшированными данными с RID это один доступ, с Б+ деревом как минимум 2 (проход по дереву + прыжок на запись). А джойны самая дорогая операция.
Ну а для FK можно делать и более сложные структуры. В любом случае FK по RID не проблема.


S>А для кластерного индекса (который, обыкновенно, и делается для PK) разница будет еще меньше. Если ты в этом не уверен, то я тебе намекну — стоимость join зависит только от количества сканируемых страниц. Вот и оцени разницу для clustered int PK и для 16-byte RID. Никаких разов, уверяю тебя, ты даже в некластерном варианте не получишь.
Ну да и много у тебя клястерных индексов????? Давай посчитаем соотношения. Кроме всего прочего никто не мешает производить разные дейстия поиск в зависимости от метаданных либо прямая ссылка, либо поикс в кластерном индексе

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

S>>Ну, во-первых, размер RID как минимум в 4 раза больше стандартного INT, который используется для FK.
S> Зачем ему быть таким же большим, если это только номер записи???? Являющийся и уникальным ID.
Ну а как ты хотел? Либо это — физический указатель на запись, который самодостаточен для ее извлечения. Тогда в него включен идентификатор БД, файла, страницы в файле, и номер записи в странице. Не меньше 16 байт! А если это — всего лишь "номер записи" — тогда, извини, никакого выигрыша не будет. Знаешь, почему? Да потому, что его придется преобразовывать каким-то образом в RID! А это и есть индекс, от которого ты стараешься избавиться.
S> Почему то я тебе не верю. Или опыт у меня маленький. Проигрыш Б+ деревьев по отношению Хэш таблицы в 4 раза, а разница хэш таблиц по сравнению с массивом это уже десятки раз. При этом учитывая что данные либо кэшируются а памяти (либо кэшируются на файловом уровне либо как в SQL на уровне страниц впринципе механизм одинаковый) и при работе с кэшированными данными разница весьма ощутима, даже не с кэшированными данными с RID это один доступ, с Б+ деревом как минимум 2 (проход по дереву + прыжок на запись). А джойны самая дорогая операция.
Опыт у тебя маленький. Ты считаешь не те операции. При работе в памяти соотношения будут похожие. Но как только ты залудишь работу со страничным кэшем, как в настоящих серверах, соотношения станут совсем другими. Я не могу понять, почему ты не хочешь читать учебники. Фраза про "два доступа для B+ против одного для RID" ясно это показывает. При выполнении Join никаких проходов и прыжков не делается. Правильный способ оценить — посчитать общее количество сканируемых страниц. Ты что, вправду думаешь, что B+ tree индекс удвоит количество страниц? Ну сходи в MS SQL Enterprize Manager — там есть страничка, которая показывает размеры таблиц и индексов. А сколько раз там на каждую страницу косвенная адресация в CPU происходит — никого не интересует. Не влияет это на стоимость.

S> Ну да и много у тебя клястерных индексов?????
Да мне ровно 1 хватит! Индекс по PK! Ты пойми, что вся разница между твоим подходом и моим — это индексация по PK. Потому, что индексация по FK все равно нужна, RID это или Identity.
S>Давай посчитаем соотношения. Кроме всего прочего никто не мешает производить разные дейстия поиск в зависимости от метаданных либо прямая ссылка, либо поикс в кластерном индексе
Да не спорю я. Просто твои ожидания различий в быстродействии RID против кластерных индексов основаны на заблуждениях.

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

S>> И при этом огромные затраты на подчиненные записи. Например сточная часть документа. И тянется огромный индекс на всю таблицу.
B>Какие затраты? Какой индекс? Ничего никуда не тянется...

Реляционная таблица в принципе не может быть быстрой без индекса.
Так что без индексов нет ни одной реляционной базы данных, а вот их количество определяется требованием к скорости обработки.

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

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

S>> Реляционные базы это выхолощенные иерархические, где применяется очень маленький набор подходов. Да это надежно, но не эффективно.
B>Это очень эффективно, потому как быстро, просто и надежно.

Про эффективность говорить не приходится.
Самая крутая РСУБД Oracle "работает одиннаково медленно" на любом объеме данных — описание дано программистом довольно двано работающим с Oracle.

При правильном использовании (как и в любой задаче) применение иерархических СУБД дает примерно выигрыш от 20 до 50 раз по скорости работы (при тех же аппаратно-технических требованиях)

Примеры можно взять из многочисленных success story например на сайте www.instersystems.ru

Если не смотреть на забугорников — то достаточно посмотреть на последние billing системы российских разработчиков (http://www.mobill.ru/csp/komta/index.csp) — просто перевод с SQL базы на эмуляцию SQL на иерархии.

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

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

S>>>Ну, во-первых, размер RID как минимум в 4 раза больше стандартного INT, который используется для FK.
S>> Зачем ему быть таким же большим, если это только номер записи???? Являющийся и уникальным ID.
S>Ну а как ты хотел? Либо это — физический указатель на запись, который самодостаточен для ее извлечения. Тогда в него включен идентификатор БД, файла, страницы в файле, и номер записи в странице. Не меньше 16 байт! А если это — всего лишь "номер записи" — тогда, извини, никакого выигрыша не будет. Знаешь, почему? Да потому, что его придется преобразовывать каким-то образом в RID! А это и есть индекс, от которого ты стараешься избавиться.
Это делается за счет кэширования информации о страницах в виде массива, как для файловых страниц так и для страниц сервера. И доступ осуществляется как RID shr 13 получаем адрес страницы.
( при 8 кб размере страницы) и RID AND ((1 SHL 13)-1). Как видишь за две операции получаем нужныю страницу и положение в ней.
S>> Почему то я тебе не верю. Или опыт у меня маленький. Проигрыш Б+ деревьев по отношению Хэш таблицы в 4 раза, а разница хэш таблиц по сравнению с массивом это уже десятки раз. При этом учитывая что данные либо кэшируются а памяти (либо кэшируются на файловом уровне либо как в SQL на уровне страниц впринципе механизм одинаковый) и при работе с кэшированными данными разница весьма ощутима, даже не с кэшированными данными с RID это один доступ, с Б+ деревом как минимум 2 (проход по дереву + прыжок на запись). А джойны самая дорогая операция.
S>Опыт у тебя маленький. Ты считаешь не те операции. При работе в памяти соотношения будут похожие. Но как только ты залудишь работу со страничным кэшем, как в настоящих серверах, соотношения станут совсем другими. Я не могу понять, почему ты не хочешь читать учебники. Фраза про "два доступа для B+ против одного для RID" ясно это показывает. При выполнении Join никаких проходов и прыжков не делается. Правильный способ оценить — посчитать общее количество сканируемых страниц. Ты что, вправду думаешь, что B+ tree индекс удвоит количество страниц? Ну сходи в MS SQL Enterprize Manager — там есть страничка, которая показывает размеры таблиц и индексов. А сколько раз там на каждую страницу косвенная адресация в CPU происходит — никого не интересует. Не влияет это на стоимость.
Понимаешь я сам работаю с файлами, работаю со страницами и могу сказать, что при кэшированных страниц очень быстро. Как доступ так и запись.
Если же использовать B+ tree вместо RID разница сразу бросается в глаза. ( правда к миллионам записей)

Говоря о нехватке памяти то 64 процессоры снимают эти ограничения и все идут к этому. Так что все о чем ты говоришь это уже анахронизм.

Объясни механизм Select d.Docid,s.Descr,d.Количество,r.Descr
From d,s,r
Where (D.Toard=S.ID) and (D.Изм=r.ID) ??????
То есть никаких прыжков ???? Все очень плавно при ID PK или RID.
S>> Ну да и много у тебя клястерных индексов?????
S>Да мне ровно 1 хватит! Индекс по PK! Ты пойми, что вся разница между твоим подходом и моим — это индексация по PK. Потому, что индексация по FK все равно нужна, RID это или Identity.
S>>Давай посчитаем соотношения. Кроме всего прочего никто не мешает производить разные дейстия поиск в зависимости от метаданных либо прямая ссылка, либо поикс в кластерном индексе
S>Да не спорю я. Просто твои ожидания различий в быстродействии RID против кластерных индексов основаны на заблуждениях.
Кроме всего прочего на RID действительно объектный код быдет работать намного быстрее и не отличатся от обычного объектного программирования.
А вот теперь Этот же самый запрос но усложненный кодга в зваисимости от товара нужно вычислять еще кучу всяких данных и ветвления могут быть очень разнообразными и одним запросом не обойтись либо на каждом шаге генерить новые и с клиента, как впрочем это делается и сейчас.
Второй вопрос как поступать с неопределенными полями когда поле может ссылаться на разные таблицы ????
Опять клиент, опять индекс.