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

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

S>>Я же сказал — типов около 1000. А 1e7 экземпляров — фигня для OLTP системы. Прикинь, сколько объектов класса ПозицияНакладной может жить в типичной системе складского учета.

AVK>Вот к примеру кондитерская фабрика. В среднем ок. 100 позиций в накладной, ок. 200 накладных в сутки (оптовые продажи). При минимальной 3-хскладовой системе имеем 5 накладных (прих., расх., 2 перемещения). Итого 100 тыс. записей в сутки. Хранить в оперативной БД нужно данные минимум за пару лет.
AVK>100тыс. * 365 * 2 это почти 1е8. И это довольно скромная оценка. Предлагаю взять 1е9 записей как верхнюю оценку.

Да хоть 1е10. Суть от этого не меняется. Мыже говрим о данных объекта которое может считываться в поле или другим методом доступ к полям через Inline свойства и хранится в обычной таблице.
Тот же скомпилированный проход как и при SQL.
JIT тоже очень хорошо оптимизирует выборки. А вот разруливание сложных ситуаций например с неопределенными типами полей и виртуальной сущности уже ложится полностью на объект. И максимум замедление при этом будет в 2 раза зато гибкость трудно посчитать.

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

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

А>Relational database management system
А>The remainder of the data used by the LMS is stored in a third-party relational database management system (RDBMS). Although the RDBMS is a third-party product, it is a fundamental component of the Lotus Learning Management System.
Слово Learning в названии не смущает? Это компонент для обучения.
Когда говорят Lotus, то обычно подразумевают систему документооборота Notes/Domino. Так вот там, "под низом" никакой реляционностью и не пахнет, я вас умоляю...

А> Data regarding user privileges, courses, and resources is stored in the database management system and accessed as needed.
А>как я и предполагал под низом одна из 3х бд db2, oracle или mssql
Е))))))))))))))))
А из чего сделан такой вывод? для перечисленной функциональности вполне хватит jet'а или вообще какой-нибудь embedded приблуды. А если большие базы для этого использовать, то под сам лотус ничего не останется. Этот зверек один из самых прожорливых, там и клиент-то такой, что вздрогнешь, а про сервер я вообще молчу.
Ты хоть в глаза-то лотус этот видел?

Короче, не надо на лотус смотреть, лучше зажмуриться.

Здравствуйте, Serginio1, Вы писали:
S>Select from * where IAmountable.Amount() > 100.0 and ISecuredObject.AllowsAccess((Context.User as Employee).Manager)
S> Ну простым перебором по 50000 это вообще милисекунды.
Нда. То есть никаких планов запроса, кроме прямого перебора, ты предложить не можешь. Насчет милисекунд на 50000... Во-первых, ты не знаешь, как реализован метод IAmountable.Amount(). А я напомню, что у нас нашлось еще и 20 разных его реализаций. Во-вторых, у нас как минимум 5 одновременных R/W транзакций, и 50 R (это я считаю, что 90% времени пользователь тормозит и запросов не отправляет) и требования изоляции еще никто не отменял. Будем ставить блокировки? Вот почему-то блокирующие RDBMS не считают это такой тривиальной задачей, и избегают row-level локов поелику возможно. А у нас тут значит рррррррррррраз за миллисекунды выдали 50000 локов, и тут же отдали. Интересно.
S>А если ISecuredObject.AllowsAccess((Context.User as Employee).Manager)==false то вообще бегать.
Этого утверждения я не понял. Ты имеешь в виду то, что некоторые реализации ISecuredObject могут всегда возвращать false из AllowAccess? Да ну! Так не бывает. Внутри какая-то логика сидит.
S>>Да ты пока еще ничего не объяснил. Продолжай. Расскажи мне, каким алгоритмом мы будем выполнять запрос.
S> Учитывая, что за выборку отвечает некий объект, считывая данные в поле объекта. Все очень просто.
Нда. Или я плохо спрашиваю, или ты просто не имеешь представления о чем говоришь. Некий объект и отвечая — это фигня.

Лирическое отступление: OLTP систему нельзя строить на прямом переборе. Масштабируемость никакая! Почему-то даже в случае структур, т.е. не то что VMT — вообще методов нет, RDBMS занимаются всякой ерундой — статистикой, индексированием... А ты утверждаешь, что отказ от этого ухудшит производительность не более чем в 2 раза... Да нет. Все ухудшится как минимум до N/logN. Это если RDBMS не владеет семантическими данными, типа check constraint Amount<100. Давай оценим, насколько твой способ хуже. Уже при N=50000 логарифм по основнию 128 (пусть у нас столько ключиков в B-tree) даст чуть больше 2. То есть нам потребуется прочитать не более 3 страниц индекса перед тем, как начать сканировать данные. И чем выше селективность предиката, тем лучше будет результат (а это так и есть — как правило, запросы возвращают разумное количество данных). Твой алгоритм будет вынужден честно прокачать 50000/128 = ~390 страниц. Хорошо, предположим отобранные данные занимают еще 10 страниц. Index seek читает 13 страниц, что примерно в 30 раз меньше алгоритма прямого перебора. Неудивительно, что на www.tpc.org не видно и не слышно о результатах ODBMS.

А если ты "неким объектом" называешь тот самый оптимизирующий query evaluator — то не скрывай уж от общественности секрет серебряной пули. Черт с ним, алгоритм построителя плана можешь не рассказывать — расскажи сам план, а?

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

S> Ну ну. Какое елозание если страницы кэшированы в памяти.
Память — не резиновая, а ты вынужден весь хеш в памяти держать.

S> А на Б+ дереве как бы там не было а в зависимости от количества уровней обратится придется еще больше, т.к. в среднем за 1.3 попытки находится результат в Хэш таблице. плюс Log(N) сравнений.
Давай считать. Хеш таблица на кучу записей в памяти. Пришел другой запрос, к другой большой таблице. Две в память уже не влезают, по частям хеш-таблицу выгружать смысла не имеет, поэтому она вся из памяти выкидывается и подгружается новая, тоже целиком.
B-Tree же позволяет работать только с частью индекса, в итоге дисковыс операций существенно меньше.
На виртуальную память надеяться не стоит, при таких интенсивных нагрузках — это очень не эффективный механизм, поэтому все БД от виртуальной памяти бегают и берут ее функции на себя.

И еще один момент, про который ты забываешь. B+Tree индекс — отсортирован, а хешь нет. Это означает, что параллельные запросы по одному и тому же B-tree индексу, гарантировано обходят записи в одном и том же порядке, а при изменениях позволяют реализовать очень эффективный механизм блокировок на DAG'ах.
В случае же хеша, порядка доступа никто не гарантирует, что неизбежно будет приводить к дедлокам.
Таким образом, если в грамотно спроектированной системе на Б-дереве можно гарантировать отсутствие дедлоков, то в системе на хеш индексах
не смотря на все усилия разработчика, такого гарантировать нельзя. В принципе эта проблема решаема, но нафиг надо...

S> Все зависит от ситуации. Тоесть собирается вся статистика по всем 100 000 для различный запросов ????? Да там статистика больше базы будет которая кто му же сильно меняется.
Ну статистика же не в тупую собирается, а с умом...

S>>>Но если брать некий усредненный алгоритм, то в среднем он и будет оптимальным, нежели ослеживать статистику по всем товарам.
Хха. Джоин двух больших таблиц в одной из которых предикату удовлетворяют 10 записей, а в другой 100000 очень сильно зависит от порядка в каком ты этот джойн будешь делать. А без статистики правильный порядок не угадаешь.

S> Очень спорно, все зависит от ситуации. Значит ты не веришь в теориЮ Вероятностей???
Ну и как теорвер поможет в ситуации описанной выше?

S> Нет конечно, но промежуточные результаты вполне возможно вычислять. Или это прерогатива только клиента ????
Промежуточные результаты чего?

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

возвращают разумное количество данных). Твой алгоритм будет вынужден честно прокачать 50000/128 = ~390 страниц. Хорошо, предположим отобранные данные занимают еще 10 страниц. Index seek читает 13 страниц, что примерно в 30 раз меньше алгоритма прямого перебора. Неудивительно, что на www.tpc.org не видно и не слышно о результатах ODBMS.

S>А если ты "неким объектом" называешь тот самый оптимизирующий query evaluator — то не скрывай уж от общественности секрет серебряной пули. Черт с ним, алгоритм построителя плана можешь не рассказывать — расскажи сам план, а?

Тяжело отвечать т.к. на данном этапе замучен бухгалтерией, но попытаюсь в кратце. Весь твой пример легко строится на обычных запросах, который генерируется на основании метаданных но с описанных на уровне объектов. А вот другой вопрос по неопределенным типам объекта здесь никакого плана не сделаешь, т.к. тип определяется только на момент получения данных об объекте, а таких ситуаций особенно в бухгалтерии пруд пруди.
Вопрос все 50 000 Amount<100. А построить индекс на все Amount тоже непроблема или вообще на все случаи жизни по всем всевозможным сочитанием полей. При всех записях Amount<100 тебе придется прочитать все данные но через индекс. И вот если Amount не есть поле объекта, а поле подчиненного объекта, то так или иначе придется строить полные вычисления, либо строить совсем другой алгоритм, в зависимости от затрагиваемых объектов (таблиц). И понятно, что такая задача не совсем тривиальна, но вполне вполнима.
А насчет 50 000 вообще не очем говорить.

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

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

S>> Ну ну. Какое елозание если страницы кэшированы в памяти.
M>Память — не резиновая, а ты вынужден весь хеш в памяти держать.

S>> А на Б+ дереве как бы там не было а в зависимости от количества уровней обратится придется еще больше, т.к. в среднем за 1.3 попытки находится результат в Хэш таблице. плюс Log(N) сравнений.
M>Давай считать. Хеш таблица на кучу записей в памяти. Пришел другой запрос, к другой большой таблице. Две в память уже не влезают, по частям хеш-таблицу выгружать смысла не имеет, поэтому она вся из памяти выкидывается и подгружается новая, тоже целиком.

Да смысл Хэш таблицы в том, что за 1 вычисление ты находишь смещение нужной записи, в среднем за 1-1.5 обращения если есть коллизии. И не важно где таблица находится в памяти или на диске, по сравнению с 2-3 тебе придется обратится к диску столько сколько количество уровней.
M>B-Tree же позволяет работать только с частью индекса, в итоге дисковыс операций существенно меньше.
Если уровней больше одного то не прав. Правда нужно оговорится, что обычно при частом обращении Root уровень будет всегда в памяти.
M>И еще один момент, про который ты забываешь. B+Tree индекс — отсортирован, а хешь нет. Это означает, что параллельные запросы по одному и тому же B-tree индексу, гарантировано обходят записи в одном и том же порядке, а при изменениях позволяют реализовать очень эффективный механизм блокировок на DAG'ах.

Разговор у нас вначале шел о Кубах и их построении. Я утверждаю, что построение их на Хэш таблицах с последющей сортировкой, даст как минимум 4 кратное ускорение если не больше.

M>В случае же хеша, порядка доступа никто не гарантирует, что неизбежно будет приводить к дедлокам.
Почему не блокировать так же как и обычные таблицы по строкам, по страницам итд, причем при рехеше получается 2 таблицы с которыми могут работать разные транзакции. Абсолютно тот же механизм
M>Таким образом, если в грамотно спроектированной системе на Б-дереве можно гарантировать отсутствие дедлоков, то в системе на хеш индексах

О хешах следует говорить при их применени для первичных ключей, где сортированность вещь не нужная и для построении группировок с последующей сортировкой.

S>> Все зависит от ситуации. Тоесть собирается вся статистика по всем 100 000 для различный запросов ????? Да там статистика больше базы будет которая кто му же сильно меняется.
M>Ну статистика же не в тупую собирается, а с умом...
Согласен, но всех ситуаций не предусмотришь. Обычно это может касеться часто используемых запросов и поностью согласуются с Теорией Вероятностей основанной на статистике.


S>> Нет конечно, но промежуточные результаты вполне возможно вычислять. Или это прерогатива только клиента ????
M>Промежуточные результаты чего?
Часто при проведении документов, нужно вычислять огромое количество результатов, что бы правильно сделать проводки, если делать все с клиента никаких проблем, а еще хотелось бы и в ХП.

Здравствуйте, Sinclair, Вы писали:
Вот почему-то блокирующие RDBMS не считают это такой тривиальной задачей, и избегают row-level локов поелику возможно. А у нас тут значит рррррррррррраз за миллисекунды выдали 50000 локов, и тут же отдали. Интересно.

Вообще паралелное чтение и запись в любом случае зло, извежать которое можно многим путями которые много раз описывал и имеются в практике.
S>Лирическое отступление: OLTP систему нельзя строить на прямом переборе. Масштабируемость никакая! Почему-то даже в случае структур, т.е. не то что VMT — вообще методов нет,
Это кто тебе сказал, что у структур нет методов ??? То, что их нет в SQL это совсем не значит, что их нет. РБД это хранилище структур с описанными связями. И построение ОО над РБД задача если не тривиальная, то вполне выполнимая. И пусть занимется
RDBMS занимаются всякой ерундой — статистикой, индексированием..., как и раньше
А ты утверждаешь, что отказ от этого ухудшит производительность не более чем в 2 раза...
Да утверждаю. Правда при условии, что Amount будет полем обрабатываем таблицы, что легко получить обрабатывая метаданные объекта, которые дополнительно должны быть описаны.
Кстати очень понравилась ECO.

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

S> Да смысл Хэш таблицы в том, что за 1 вычисление ты находишь смещение нужной записи, в среднем за 1-1.5 обращения если есть коллизии.
Так тебе надо ее построить в памяти с начала.

S> Разговор у нас вначале шел о Кубах и их построении. Я утверждаю, что построение их на Хэш таблицах с последющей сортировкой, даст как минимум 4 кратное ускорение если не больше.
Ну тут ты совсем неправ. Во первых на таких объемах хеш таблица просто в память не влезет, а во вторых у хеша перед деревом в принципе не такое преимущество — максимум десятки процентов.

S> Почему не блокировать так же как и обычные таблицы по строкам, по страницам итд
Потому что в этом случае нет гарантии, что дедлок не случится.

S>Абсолютно тот же механизм
Да понятно, что тот же, но в этом случае есть шанс нарваться на дедлок.

S> О хешах следует говорить при их применени для первичных ключей, где сортированность вещь не нужная и для построении группировок с последующей сортировкой.
Как раз там отсортированность очень прогодилась бы. Скажем запрос where ID>5 при обращении к диску в силу отсортиованности данных будет считываьб последовательные страницы, а в случае хеша — из разных частей диска. Что вообщем тоже для перфоманса не подарок.

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

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

S>> Да смысл Хэш таблицы в том, что за 1 вычисление ты находишь смещение нужной записи, в среднем за 1-1.5 обращения если есть коллизии.
M>Так тебе надо ее построить в памяти с начала.
Зачем, чем Хэш таблица отличается от обычной таблицы????
Это набор записей, где номер нужной записи получается путем вычисление хэша ключа.
Единственная их проблема это ReHash, когда нужно перестраивать всю таблицу и в зависимости от ее размера это может быть проблемой, но увеличивая каждый раз ее в 2 раза по необходимости или во время профилактики по ночам.

S>> Разговор у нас вначале шел о Кубах и их построении. Я утверждаю, что построение их на Хэш таблицах с последющей сортировкой, даст как минимум 4 кратное ускорение если не больше.
M>Ну тут ты совсем неправ. Во первых на таких объемах хеш таблица просто в память не влезет, а во вторых у хеша перед деревом в принципе не такое преимущество — максимум десятки процентов.
Чем Хэш таблица отличается от обычной таблицы????
Почему то тесты показывают обратное.
S>> Почему не блокировать так же как и обычные таблицы по строкам, по страницам итд
M>Потому что в этом случае нет гарантии, что дедлок не случится.

S>>Абсолютно тот же механизм
M>Да понятно, что тот же, но в этом случае есть шанс нарваться на дедлок.
С такой же вероятностью как и 2-3 (B-tree). Механизмы блокировки теже.
S>> О хешах следует говорить при их применени для первичных ключей, где сортированность вещь не нужная и для построении группировок с последующей сортировкой.
M>Как раз там отсортированность очень прогодилась бы. Скажем запрос where ID>5 при обращении к диску в силу отсортиованности данных будет считываьб последовательные страницы, а в случае хеша — из разных частей диска. Что вообщем тоже для перфоманса не подарок.
Ну такой запрос для первичных ключей мало вообще где используется т.к. первичный ключ предназначен для связей, а не использоваание его как побочный эффект.

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

S>Тяжело отвечать т.к. на данном этапе замучен бухгалтерией, но попытаюсь в кратце.
Да я не тороплюсь. Так что как разгрузишься — возвращайся
S>Весь твой пример легко строится на обычных запросах, который генерируется на основании метаданных но с описанных на уровне объектов.
Все, о чем я тебя прошу — это расшифровать слово "легко". Какие метаданные ты имеешь в виду?
S>А вот другой вопрос по неопределенным типам объекта здесь никакого плана не сделаешь, т.к. тип определяется только на момент получения данных об объекте, а таких ситуаций особенно в бухгалтерии пруд пруди.
Не, так мы делаьт не будем. Для упрощения все объекты типизированы статически.
S>Вопрос все 50 000 Amount<100. А построить индекс на все Amount тоже непроблема или вообще на все случаи жизни по всем всевозможным сочитанием полей.
S> При всех записях Amount<100 тебе придется прочитать все данные но через индекс. И вот если Amount не есть поле объекта, а поле подчиненного объекта, то так или иначе придется строить полные вычисления, либо строить совсем другой алгоритм, в зависимости от затрагиваемых объектов (таблиц).
Это вообще не поле, а метод. Так что только "строить совсем другой алгоритм".
S>И понятно, что такая задача не совсем тривиальна, но вполне вполнима.
Ну так ты расскажи — как именно она выполнима? А то я тоже могу сказать, что разложение числа на простые множители быстрее, чем за exp(N), не совсем тривиально, но вполне выполнимо.
S> А насчет 50 000 вообще не очем говорить.
Хорошо, пусть будет 50 000 000. Хотя и для 50000, как я тебе показал, разница уже настолько существенная, что никто не станет пользоваться такой системой.
Да, совсем забыл — применение алгоритмоя прямого перебора, помимо очевидного всем, кроме тебя, оверхеда, приносит еще и проблемы с concurrency. Дело в том, что если хотя бы один объект нужного нам класса в данный момент заблокирован на запись, ВСЕ запросы будут курить, пока эта транзакция не завершится. Наличие индексов позволяет одновременно выполнять запросы к тем областям екстента, где нет эксклюзивных блокировок.

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

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

S>Единственная их проблема это ReHash
Это не единственная проблема, по ночам не сделаешь, достаточно много систем работают 24x7

S>Почему то тесты показывают обратное.
Значит такие тесты.

M>>Да понятно, что тот же, но в этом случае есть шанс нарваться на дедлок.
S> С такой же вероятностью как и 2-3 (B-tree).
В том то и разница, что в хеше дедлок на одном индексе, а в Б-дереве надо минимум два, что позволяет вообще свести эту вероятность к нулю при грамотном проектировании.

S> Ну такой запрос для первичных ключей мало вообще где используется
Еще как используется.

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

S> Вообще паралелное чтение и запись в любом случае зло, извежать которое можно многим путями которые много раз описывал и имеются в практике.
Как интересно... Можно ссылочку на описане хотя бы одного путя избежать R/W в OLTP задачах? Например, при резервировании авиабилетов. Выделение каждому пассажиру своей авиакомпании не предлагать.
S> Это кто тебе сказал, что у структур нет методов ??? То, что их нет в SQL это совсем не значит, что их нет. РБД это хранилище структур с описанными связями. И построение ОО над РБД задача если не тривиальная, то вполне выполнимая. И пусть занимется
Видишь ли, наличие O/R маппинга опять же не делает из RDBMS OODBMS. Никоим боком. Это всего лишь stateful сервер приложений, интегрированный с RDBMS. Вот Cache хотя бы сделала многомерные индексы...
S>RDBMS занимаются всякой ерундой — статистикой, индексированием..., как и раньше
S>А ты утверждаешь, что отказ от этого ухудшит производительность не более чем в 2 раза...
S> Да утверждаю. Правда при условии, что Amount будет полем обрабатываем таблицы, что легко получить обрабатывая метаданные объекта, которые дополнительно должны быть описаны.
Вот именно. Ты вполне готов строить RDBMS поверх RDBMS. Как, впрочем, и все остальные. То есть, пока поле — это поле, а объект — это запись, все в порядке. можно делать запросы почти так же быстро, как в обычной RDBMS. При условии, что ты будешь пользоваться статистикой и индексированием. Увы, на этом уровне реализовано (в лучшем случае ) наследование. Ни полиморфизма ни инкапсуляции гарантированно нет. А как только мы пытаемся их включить, производительность запросов превращается из M*log(N) в N^M. Где M — количество екстентов в джойне.
S>Кстати очень понравилась ECO.
Это кто?

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

M>>Как раз там отсортированность очень прогодилась бы. Скажем запрос where ID>5 при обращении к диску в силу отсортиованности данных будет считываьб последовательные страницы, а в случае хеша — из разных частей диска. Что вообщем тоже для перфоманса не подарок.
S> Ну такой запрос для первичных ключей мало вообще где используется т.к. первичный ключ предназначен для связей, а не использоваание его как побочный эффект.
Про первичные ключи — согласен. ODBMS обычно предпочитают хэш-индексы именно потому, что предоставляют в первую очередь traversing, а для него B-tree проигрывает. Возможности range-запросов в них сводят к минимуму, ну либо таки делают деревья для всего остального.

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

S> ODBMS обычно предпочитают хэш-индексы
Я припоминаю только одну базу, которая пользовала хеш-индекс, но это было что-то древнее, типа клариона и обходилось это неоправдано дорого с точки зрения места на диске, в итоге уже в следующей версии на это дело забили.
Для реляционных баз хеш далеко не лучшее решение, как ни крутись, но при использовании хеш таблиц обмен с диском интенсивнее и меньше поддается оптимизации, и я не очень понимаю, что меняется, если мы начинаем работать с объектами.

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

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

S>>Тяжело отвечать т.к. на данном этапе замучен бухгалтерией, но попытаюсь в кратце.
S>Да я не тороплюсь. Так что как разгрузишься — возвращайся
S>>Весь твой пример легко строится на обычных запросах, который генерируется на основании метаданных но с описанных на уровне объектов.
S>Все, о чем я тебя прошу — это расшифровать слово "легко". Какие метаданные ты имеешь в виду?

Давай разберем структуру имеющую поля как числовые, строковые и ссылочные. Обычно это делается через описание полей (заголовочная часть таблицы) и прописания связей в SQL которые по сути и прописывают поведение записей на которых затем и строится запрос. Но возможно делать описание поведения структуры путем введения некоторой большей функциональности. Помоему в клиппере даже хранился скомпилированный код например для вычисления индексного выражения и функции сравнения.
S>>А вот другой вопрос по неопределенным типам объекта здесь никакого плана не сделаешь, т.к. тип определяется только на момент получения данных об объекте, а таких ситуаций особенно в бухгалтерии пруд пруди.
S>Не, так мы делаьт не будем. Для упрощения все объекты типизированы статически.
S>>Вопрос все 50 000 Amount<100. А построить индекс на все Amount тоже непроблема или вообще на все случаи жизни по всем всевозможным сочитанием полей.
S>> При всех записях Amount<100 тебе придется прочитать все данные но через индекс. И вот если Amount не есть поле объекта, а поле подчиненного объекта, то так или иначе придется строить полные вычисления, либо строить совсем другой алгоритм, в зависимости от затрагиваемых объектов (таблиц).
S>Это вообще не поле, а метод. Так что только "строить совсем другой алгоритм".

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

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

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

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

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

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

Ну а вчем разница от б 2-3 если это не кластерный индекс, что впрочем можно делать и на хэш таблицах.
S>>Единственная их проблема это ReHash
M>Это не единственная проблема, по ночам не сделаешь, достаточно много систем работают 24x7
Все зависит от условий. Опять же я Хэш таблицу поднял только для использования группирования данных путем хранения в ней Key, Value что соответствуе клястерному инддексу.
S>>Почему то тесты показывают обратное.
M>Значит такие тесты.
Покажи свои.
M>>>Да понятно, что тот же, но в этом случае есть шанс нарваться на дедлок.
S>> С такой же вероятностью как и 2-3 (B-tree).
M>В том то и разница, что в хеше дедлок на одном индексе, а в Б-дереве надо минимум два, что позволяет вообще свести эту вероятность к нулю при грамотном проектировании.
Не совсем понял, для хэш таблицы я также могу блокировать не только на уровне записи но и на уровне страницы да и всей таблицы, т.к. данные Хэш таблицы тоже хранятся постранично.
S>> Ну такой запрос для первичных ключей мало вообще где используется
M>Еще как используется.
Ага это выглядит примерно так, выдай мне все объекты адрес которых больше некоторого адреса.
А вот когда для первичных ключей используют испльзуют осмысленный атрибут тогда да.
Но поторюсь Хэш таблицы вылезли при обсуждении использовании их при группировании данных.

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


S>>Единственная их проблема это ReHash
M>Это не единственная проблема, по ночам не сделаешь, достаточно много систем работают 24x7
Это уже другой врпрос. Но например для некотрых наборов записей их количество ограничено и вполне можно применять и Хэш таблицы. Все от ситуации.
S>>Почему то тесты показывают обратное.
M>Значит такие тесты.

Для примера, приведу индекс CDX в нем придусмотрена сжатие ключей, что бы их поместилось больше на странице и соответственно уменьшения количества обращений к диску и при этом о поиске половинным делением нет и речи. И тормоза.
Не большой вопрос как сказывается увеличение памяти (Athlon 64 вроде как вышел) и применение Raid массивов на производительность.
А вот тесты на памяти дают 4 кратное превосходство Хэш таблиц над Б+ деревьями.

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

S>Вот именно. Ты вполне готов строить RDBMS поверх RDBMS. Как, впрочем, и все остальные. То есть, пока поле — это поле, а объект — это запись, все в порядке. можно делать запросы почти так же быстро, как в обычной RDBMS. При условии, что ты будешь пользоваться статистикой и индексированием. Увы, на этом уровне реализовано (в лучшем случае ) наследование. Ни полиморфизма ни инкапсуляции гарантированно нет. А как только мы пытаемся их включить, производительность запросов превращается из M*log(N) в N^M. Где M — количество екстентов в джойне.

Ну ачто делать. Хотя опять ты больше напираешь на массовые запросы. Но иногда и их нужно использовать с применением полиморфизма, когда нужно найти то не зная что. Обычно полиморфизм нужен при неопределенных типах полей и при разветвленных вычислениях со множественными If, где SQL запрос просто не построить.
А разряженные индексы это не проблема.
S>>Кстати очень понравилась ECO.
S>Это кто?

Enterprise Core Objects Продолжение Bold
http://www.borland.ru/delphi_net/architect/index.html

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


S> Все зависит от условий. Опять же я Хэш таблицу поднял только для использования группирования данных путем хранения в ней Key, Value что соответствуе клястерному инддексу.
Бррр... Уж для группирования-то хешь зачем использовать? Какой Key-Value, и причем здесь кластерный индекс?

S> Не совсем понял
Еще раз. B tree сортирован, хеш — нет. сортировка позволяет снизить вероятность дедлоков.

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

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


S> А вот тесты на памяти дают 4 кратное превосходство Хэш таблиц над Б+ деревьями.
Ну ты пойми, что в реальных системах никогда у тебя не бует такого счастья, как все в памяти.