Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8   вперед  Ctrl      все
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Андрей Леонидович
Guest
Нет, vybegallo, не хотелось мне никого лягать...
Видел ли я хоть один план ?
Написал ли я хоть одну программу ?
Спроектировал ли я хоть одну базу данных ?
Не Вы первый здесь очень хочет, чтобы я оказался не компетентным...
22 дек 04, 01:33    [1198438]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Андрей Леонидович
Guest
Да, "их есть". И я это написал черным по белому. А Вы опять спрашиваете, как ни в чем не бывало...
Спокойной ночи.
22 дек 04, 01:37    [1198439]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
vybegallo
Андрей Леонидович
vybegallo !

1. О какой теории оптимизации запросов в "реляционных" СУБД Вы говорите ? Когда нет даже самих реляционных СУБД.
2. Я уже много раз высказывал свое мнение про ООП и его отношение к моделям данных и базам данных. Под навигацией я понимаю исключительно навигацию, а под семантикой исключительно семантику.
3. Рад, что повеселил хорошего человека. Жаль, что на нешуточные аргументы (а я их уже много привел в трех темах) Вы не обратили внимание.
4. Про заранее непредусмотренную связь - серьезное заблуждение. С одной стороны не "не могут быстро", а ВООБЩЕ НЕ МОГУТ "родными" средствами. С другой стороны:

s query(1)="h2.o1,h7.o2",query(2)="o1,o2",query(3)="h2=h7"
s result=$$^%oz("query","result")

где h2 - идентификатор характеристики День рождения объекта o1 Человек, а h7 - идентификатор характеристики Примечание объекта o2 Товаро-транспортная накладная

И кто Вам сказал, что оптимизатор oz будет работать медленнее, чем оптимизатор какой-то "реляционной" СУБД ? Преподаватель что ли на лекции сообщил ?

А вот то, что за 20 лет эксплуатации разнообразных приложений в таких запросах НИ РАЗУ не возникло необходимости - это факт.


Извините, но "когда вы говорите, такое впечатление, что вы бредите".
...

Вы не первый
тут и еще пару страниц назад всё тоже самое :)
22 дек 04, 01:42    [1198440]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
vybegallo
Guest
Андрей Леонидович
Да, "их есть". И я это написал черным по белому. А Вы опять спрашиваете, как ни в чем не бывало...
Спокойной ночи.


"Тут мне карта и поперла !" (С)
Не надо нам рассказывать - вы нам ПОКАЖИТЕ хоть один такой план.
22 дек 04, 01:44    [1198441]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
vybegallo
Guest
SergSuper
vybegallo
Андрей Леонидович
vybegallo !

1. О какой теории оптимизации запросов в "реляционных" СУБД Вы говорите ? Когда нет даже самих реляционных СУБД.
...
А вот то, что за 20 лет эксплуатации разнообразных приложений в таких запросах НИ РАЗУ не возникло необходимости - это факт.


Извините, но "когда вы говорите, такое впечатление, что вы бредите".
...

Вы не первый
тут и еще пару страниц назад всё тоже самое :)


Нда... :-(
примета времени - раньше на изобретении вечного двигателя крышей съезжали, теперь - на объектных субд...
22 дек 04, 01:52    [1198444]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
Андрей Леонидович

1. Фрагмент "про MSM". И Вас что ли преподаватель подкачал ? Или знакомый какой? Конечно же, одновременный доступ к данным, транзакции, моментальные снимки и т.п. И компактность, и быстродействие - во всех мыслимых границах. Вы, видимо, так и не захотели плнять для чего нужен MUMPS.


Мне не нужны были шашечки, мне надо было ехать. Пока куча операционистов работала на вводе вкладных операций (я работал в банке), все было нормально. Но подготовки отчетов, регламентированных заметьте, выполнялись крайне долго. А для нерегламентированных отчетов вообще каждый раз надо было писать длинную программулину, хотя все могло решиться обычным селектом с 3-4 связками таблиц. Даже фокспро отчет по таким объемам данных давало за минуту, а MSM - за полчаса.

Андрей Леонидович

3. Я уже рассказывал о принципиально разной роли индексов в объектных и "реляционных" системах. Очень советую Вам обратить на это внимание.


Я, кажется, упустил это. Не могли бы Вы дать ссылку. Почему-то я считал, что роль индексов - это ускорение доступа к данным. Можно обращаться по адресам, хранящимся в индексах, но можно просто и сами индексированные данные достать. А тут - принципиально разная роль.

Андрей Леонидович

4. Правильно, правильно я "понимаю системы ERP". И про "странности" OEBS ИМЕННО ПО ЭТОМУ ПОВОДУ (!) я уже говорил, причем именно знатоков процитировал.


Ссылку, пожалуйста, дайте. Я опять что-то пропустил. В OEBS отчетов больше, чем форм ввода, да и при внедрении требуется написать кучу отчетов и немного формочек ввода и утилит взаимодействия с внешними системами. Я уж не говорю о всяких системах типа discoverer или integrator, которые ничего не вводят, но показывают данные пользователям. В R3 аналогичное деление по функционалу.

Андрей Леонидович

5. Что значит "технично пропустил" ?


То и значит. Ответ типа "оптимизатор есть, отстаньте от меня" - это не ответ. Насколько я помню, но могу и ошибаться, первый в мире стоимостной оптимизатор появился где-то в начале 90-х в базе от sybase.

А знатоки разные бывают. Один линуксолог на мой вопрос, почему редхат порушил мне диск и как с этим бороться, ответил "только идиоты используют редхат, надо использовать сусе". Ваши ответы примерно такие же. Никаких планов выполнения, никаких фактов, только реклама.
22 дек 04, 10:14    [1198900]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Насколько я помню, но могу и ошибаться, первый в мире стоимостной оптимизатор появился где-то в начале 90-х в базе от sybase.


СУБД Teradata существует уже 25 лет и там всегда был стоимостной оптимизатор. Так что первенство Sybase можно, как минимум, оспорить.


С уважением,
Константин Лисянский
http://lissianski.narod.ru
22 дек 04, 10:36    [1199023]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Alexey Rovdo

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


Все-таки надо выделять из объектных объекно-ориентированные. Кроме того, реляционные и ОО могут не только конкурировать, но сочетаться - ОРМД. И это для перспекивы "чистых" ООМД может иметь критическое значение. Возможна ситуация, когда на смену уже придут новые подходы, а ООМД так и не займет на рынке существенного места, так как ОРМД будут позволять реализовывать специализированные приложения (плохие для РМД), а типовые (бизнес приложения) - РМД. Вот Вы эту возможность не рассмвтриваете в Ваших прогнозах, и напроснано: с ней многие авторы толстых книг по БД считаются. Вы слишком упростил ситуацию в Ваших оценках, и поэтому доводы имеют существенные изъяны.
22 дек 04, 10:48    [1199123]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Андрей Леонидович
Guest
Уважаемый Al !

1. При чем здесь конкретное, неудачное приложение ? Какое это имеет отношение к ОСУБД на MUMPS ? Приложения в среде этих ОСУБД не имеют таких проблем в принципе.

2. Про индексы см. стр. 3 в теме "СУБД CACHE".

3. Про OEBS см. стр. 9 в теме "СУБД CACHE". "При внедрении нужно написать кучу отчетов". Блеск !

4. Итак, с оптимизаторами по стоимости разобрались. Работают они везде примерно одинаково. Ясно какая статистика поддерживается автоматически, а какая собирается автоматически.
Очевидно, что
- количество экземпляров объектов;
- количество экземпляров других объектов, связанных с конкретным экземпляром объекта по конкретной связи;
- количество экземпляров для каждого значения в индексах
именно поддерживаются автоматически при вводе/удалении/обновлении экземпляров.
Не сомневаюсь, что в любой "реляционной" СУБД количество записей в таблицах и количество записей для каждого значения в индексах поддерживаются автоматически при вводе/удалении/обновлении записей.
Не сомневаюсь, что в любой "реляционной" СУБД количества записей в индексе по полю "Фамилия" слева и справа от значения "Сидоров" не поддерживаются автоматически при вводе/удалении/обновлении записей.

Так чем же "реляционные" СУБД отличаются в лучшую сторону от дореляционных ОСУБД ? В худшую понятно чем. Объяснил подробно.
А в лучшую чем ?
22 дек 04, 13:37    [1200130]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
Андрей Леонидович

Далее ASCRUS странно прореагировал на то, что при использовании ОСУБД сводится к минимуму программирование нерегламентированных отчетов. И я понимаю откуда "растут ноги" у такой реакции. Вот, например, цитата из учебника-руководства по внедрению Oracle Applications 11i (приложение класса ERP):

"Если программист имеет опыт работы с инструментами Developer 2000 и Developer 6i и хорошо знаком со схемой данных Oracle Applications и языком SQL, то создание пользовательских отчетов для приложений Oracle Applications будет относительно простой задачей. Однако, следует помнить, что конечный пользователь не должен заниматься созданием пользовательских отчетов."

Вот как ! Наверное и Выши приложения так "организованы" ?
ПОЛЬЗОВАТЕЛЬСКИЕ отчеты должны создавать ПОЛЬЗОВАТЕЛИ. Так и есть, когда приложение работает в ОСУБД. И в тех, очень редких, случаях, когда невозможно получить нужный отчет с помощью объектного генератора отчетов, я стараюсь сделать все возможное, чтобы программисты ничего не программировали. В результате:

1) программисты решают более важные и интересные задачи;
2) пользователи могут создать МНОЖЕСТВО отчетов в данной "области", а не ОДИН, который им был нужен.


Вы занимаетесь только теоретическими выкладками для специализированных задач. На практике все выглядит несколько по-другому. А уж говорить о том, о чем имеете в высшей степени смутное представление и заранее враждебное настроение, не стОит.

Разумеется, в OEBS есть построитель отчетов. Да не один. Я упоминал discoverer и gldi. Но проблема в том, что для каждого предприятия и каждой страны есть своя уникальная отчетность, которая не вписывается в достаточно жесткие рамки стандартных средств. Эти отчеты все являются очень нетривиальными (можете мне поверить), и ни один пользователь не сможет их построить, а тем более, обеспечить нормальную производительность. Я уже не говорю о том, что бизнес-смысл различных параметров настройки любых (не специализированных) приложений разный, что делает невозможным использование только штатных средств построения отчетов самими пользователями.
22 дек 04, 14:21    [1200349]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
vadiminfo

Все-таки надо выделять из объектных объекно-ориентированные. Кроме того, реляционные и ОО могут не только конкурировать, но сочетаться - ОРМД. И это для перспекивы "чистых" ООМД может иметь критическое значение. Возможна ситуация, когда на смену уже придут новые подходы, а ООМД так и не займет на рынке существенного места, так как ОРМД будут позволять реализовывать специализированные приложения (плохие для РМД), а типовые (бизнес приложения) - РМД. Вот Вы эту возможность не рассмвтриваете в Ваших прогнозах, и напроснано: с ней многие авторы толстых книг по БД считаются. Вы слишком упростил ситуацию в Ваших оценках, и поэтому доводы имеют существенные изъяны.


Да в принципе и сегодня никто не мешает работать с наиболее распространенными РСУБД в стиле ООП - точно также, как это происходит и с ООСУБД. В состав многих современных средств разработки активно встраиваются средства O/R связывания (Borland - ECO II, Microsoft - Visul Studio 2005 ... ). Существуют и специализированные инструментарии с более богатыми возможностями (Open Access .NET, Open Access JDO). Все эти средства ориентированы в первую очередь на ускорение и упрощение разработки и в таких, например, сферах как ERP и MSM системы начинают преобладать. А вот дальше и возникает вопрос. Если ваша система разработана на базе принципов ООП и оперирует данными как связанными объектами, а сами данные через O/R отображение размещаются в реляционных таблицах (Oracle, SQL Server ...), то следующий вполне очевидный шаг - это перенос базы данных в ООСУБД. Сам перенос в таком случае вообще не требует усилий разработчика и сводится к замене сервера (программы переписывать нет нужды). В чем же выйгрыш? А в том, что система, спроектированная в стиле ООП, будет значительно производительнее при использовании именно ООСУБ.

Но напрактике таких ситуаций пока мало. Обычно приходится иметь дело с унаследованными системами (установленными ранее СУБД), где приложения уже написаны и ориентированы именно на парадигму РСУБД. А в таком случае, когда имеет место смешанная архитектура (объектно-реляционная), переход на ООСУБД может быть и не оправдан (все зависит от конкретной ситуации).

И наконец, очередной раз повторяю. Объектные СУБД позволяют делать все то же самое, что позволяют и реляционные системы. Отличия только в производительности тех или иных решений на разных платформах. И SQL, и индексы, и оптимизаторы запросов, и транзакции и все остальное в рамках современных ООСУБД функционируют так же.

Что касается перспективы ОРМД, то про нее мне говорить сложнее. Тем не менее мне кажется, что эти системы гораздо более уязвимы, чем РМД и ОМД. И именно потому, что пытаются сидеть на двух (а то и трех) стульях сразу. В свое время они возникли как альтернатива нараставшей войне между объектной и реляционной концепциями. Но сейчас, когда по моему мнению большинство специалистов уже признало право на существование за обеими концепциями (РМД и ОМД), роль ОРМД стоит под вопросом, и в первую очередь из-за того, что для конечного пользователя (разработчика) функционал большинства ООСУБД и РСУБД становится практически идентичным (SQL-интерфейс + ОО-интерфейс). И что получается в итоге?
Есть две принципиально разных методики разработки (с опорой на объекты и модели предметной области, и с опорой на данные и ER-инструментарий), каждая из этих методик логически приводит к выбору типа хранилища - объектного или реляционного. А вот какая методика разработки сочетается с ОР-системами мне неизвестно.
22 дек 04, 14:21    [1200350]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alex.Czech
Guest
Андрей Леонидович
Не сомневаюсь, что в любой "реляционной" СУБД количество записей в таблицах и количество записей для каждого значения в индексах поддерживаются автоматически при вводе/удалении/обновлении записей.


В индексах - да, в статистиках - нет
22 дек 04, 15:13    [1200667]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alex.Czech
Guest
Да и в индексах вообще говоря нет... потому что там информация такого рода хранится тоже в виде статистик, по крайней мере в MS SQL
22 дек 04, 15:19    [1200694]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
Alexey Rovdo
Если ваша система разработана на базе принципов ООП и оперирует данными как связанными объектами, а сами данные через O/R отображение размещаются в реляционных таблицах (Oracle, SQL Server ...), то следующий вполне очевидный шаг - это перенос базы данных в ООСУБД. Сам перенос в таком случае вообще не требует усилий разработчика и сводится к замене сервера (программы переписывать нет нужды). В чем же выйгрыш? А в том, что система, спроектированная в стиле ООП, будет значительно производительнее при использовании именно ООСУБ.


Вы все время ссылаетесь на "реляционные таблицы" и часто приводите в пример оракл. А Вы знаете, как именно хранит данные тот же оракл?

Таблица может жить в виде "обычного набора записей"; может в виде индекса то есть принципиально иной организации данных, когда в блоках данных (страницах) имеется еще и деревообразующие структуры, указатели; может храниться в кластере - в одном и том же блоке хранятся данные нескольких таблиц (мастер и детали вместе); может храниться в секциях - фактически, в нескольких таблицах. Когда дело доходит до ОР свойств, то в дело вступают еще и адреса объектов. Поскольку есть наследование (версия 9 и выше), проблем с хранением потомков других типов нет. Сами данные в зависимости от типов хранятся в разных представлениях и, возможно, отдельно от основной части строки.

А в том же каше все объекты собраны в деревья и данные хранятся в текстовом виде. Кажется, что это все как-то победнее, чем в реляционных базах, а уж в объектно-реляционных... И не очень хочется переходить на непонятно что с надежной системы проверенной временем.

Информационная система не сводится к максимально быстрому доступу на одну запись, как тут пропагандируется. Она всегда требует нерегламентированных запросов, с которыми иерархические или сетевые организации данных справляются плохо. Именно этот факт и стал причиной популярности РСУБД.
22 дек 04, 15:26    [1200742]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Alexey Rovdo
И SQL, и индексы, и оптимизаторы запросов, и транзакции и все остальное в рамках современных ООСУБД функционируют так же.


Ничем не подкреплённое утверждение. То, что оптимизатор в ООСУБД есть мы тут уже с горем пополам выяснили, а вот, как он функционирует, на основе чего принимает решения, насколько он продвинут все апологеты ООСУБД отказываются нам рассказать. Похоже, ни один из них не знает о том, как этот оптимизатор устроен.


С уважением,
Константин Лисянский
http://lissianski.narod.ru
22 дек 04, 15:54    [1200925]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Андрей Леонидович
Guest
Уважаемый Al !

Почему Вы думаете, что я занимаюсь "только теоретическими выкладками" ?
Я вот не считаю, что Вы занимаетесь только теоретическим выкладками.
Значит эти специалисты ОШИБЛИСЬ !?
Кладовщицы, мастера и начальники цехов, все-таки, делают отчеты с помощью discoverer и gldi ?
Так прямо и скажите.

Какой конкретно мой аргумент говорит о "смутном и заранее враждебном отношении" ?
22 дек 04, 16:56    [1201335]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Константин Лисянский
Alexey Rovdo
И SQL, и индексы, и оптимизаторы запросов, и транзакции и все остальное в рамках современных ООСУБД функционируют так же.


Ничем не подкреплённое утверждение. То, что оптимизатор в ООСУБД есть мы тут уже с горем пополам выяснили, а вот, как он функционирует, на основе чего принимает решения, насколько он продвинут все апологеты ООСУБД отказываются нам рассказать. Похоже, ни один из них не знает о том, как этот оптимизатор устроен.


С уважением,
Константин Лисянский
http://lissianski.narod.ru


Так же с точки зрения пользователя/разработчика. Разумеется, если мы лезем вглубь всех этих технологий, то ничего не остается как дать длинные выдержки из документации (данная документация идет в составе продукта и доступна для скачивания здесь).
Итак Versant Developer Suite 6.0:


Concepts

Index purpose

Indexes allow routines that query, create, and update objects to have quick access to the values of a particular attribute of a class.
Query routines can use indexes to filter objects so that only objects of interest within a specified range are fetched from disk. This can improve query performance in many situations.
Create and update routines can use indexes to enforce uniqueness constraints on attribute values.

Index structure

An index is set on a single attribute of a class and affects all instances of the class. It is a list of pairs consisting of key values and associated object identifiers.
There are two kinds of index structures: b-tree and hash table. Both types of structures maintain a separate storage area containing attribute values, only their organization is different. The type of structure that you want to use depends upon the types of queries you will be making.

Index constraints

There are two kinds of index constraints: "normal" and "unique." A "normal" index places no constraints on attribute values. A "unique" index requires that each instance of a class has a value in the indexed attribute that is unique with respect to the values in that attribute in all other instances of the class.
If you want to create a unique index, you can use either a b-tree or hash table structure. The only difference is that when you create the index, you specify that you want unique values.

General Rules

Indexes do not have names.
Indexes are maintained automatically.
Once created, indexes are maintained automatically, which means that they may somewhat slow the creation, updating, and deletion of instances.

...

Attributes can have two indexes.

An attribute can have up to two indexes, a b-tree index (normal or unique) and a hash table index (normal
or unique).

Each database has its own set of indexes.

When you migrate an object to a database in which its class is not defined, the class definition, index definition, and index behavior are also migrated.
When you migrate an object to a database in which its class is already defined, the migration will fail if the target database does not have the same class definition, index definition, and index behavior as the source database.
An index is set on one attribute in one class.
When you create an index, that index is created on an attribute of a class and not on an attribute in any other class. In other words, indexes are not inherited. To index subclass attributes, you need to specifically set indexes on each subclass.
This is important to remember if you are using multiple inheritance and/or are querying over members of a class and its subclasses. The general caution is that if you use multiple inheritance but treat inheriting classes separately, then you may get anomalies.

Indexes should be consistent.

Because indexes are set only on one attribute in one class, you should set corresponding indexes on all classes that have an inheritance relationship. For example, in the above, if you set an index on Person, then set the same index on Customer, Employee, Developer, and Intern.



Query Costs

One of the costs of a query is fetching data pages from disk so that the server process can evaluate objects. Once objects are in memory, applying the predicate happens quickly.
If you use no indexes, a query will fetch all data pages for a class and evaluate all objects in a single pass through the data pages. This approach optimizes the disk fetch and is appropriate if you want to return a relatively large proportion of the instances of a class.
If you have a large number of objects and want to return, say, a quarter or less of all instances, then an index can improve query performance. The tradeoff is improved query speed versus index overhead, as indexes are automatically updated when objects are added, changed, or dropped.
An index might logically be set on attributes related to domains, subclasses, and links for queries that evaluate substructures. Alternately, they may be set on a first-level attribute used frequently as a search condition or on logical object identifiers.
A b-tree index is useful for value-range comparisons, and a hash index is useful for direct comparisons of values.
A b-tree index will return objects in ascending order; to access objects in descending order, access the returned vstr or array from its end rather than beginning. However, if a query evaluates a class and its subclasses, objects are returned in ascending order in each subclass, which means that the set of all objects are not necessarily in ascending order.
If you will only be making equality comparisons, generally a hash table is better; otherwise, use a b-tree index.
Following is additional detail on how indexes are used.

Indexable Predicate Term

The system optimizer will automatically use an index in a query if a predicate term is "indexable."
A predicate term is indexable if all of the following are true.
• The evaluation attribute has an index on it.
• The evaluation attribute is not expressed in terms of a path.
• The comparison operator is appropriate to the type of index.
The following types of comparison operators can use the following types of indexes.

O_EQ
Scalar equal to
Can use either a hash or b-tree index.
If there are both kinds of indexes on the evaluation operator, the hash
index will be used.

...



Query Evaluation and B-tree Indexes

A query can use a b-tree index in an exact match or range predicate. When a b-tree index exists, each object has an entry on a leaf page of the b-tree. These leaf pages are sorted on the b-tree attribute and doubly linked.

Exact match predicate

By definition, an exact match predicate has the form (attribute == key_value).
A query with an exact match predicate will traverse a b-tree index on an attribute starting from the root page down through interior node pages, if any, to a leaf page with an entry for the key value.
If the key value cannot be located, then no object satisfies the predicate, and the query is finished. If an entry for the key value is found, then the object is retrieved into server memory from the corresponding data page whose location is stored inside the entry for the key value. If there are other predicate terms, the retrieved object is further evaluated and returned to the application if it satisfies all
predicate terms.
If the index is a unique index, the query is finished. If the index is not unique, then all objects with the key value are retrieved, evaluated, and returned if they satisfy all predicate terms.

Range predicate

By definition, a range predicate has the form (attribute >= lower_bound and
attribute <= upper_bound). An exact match predicate is a special form of a range predicate where the lower_bound is the same as the upper_bound.
Like the exact match case, a query with a range predicate traverses a b-tree index searching for an entry on a leaf page whose key value is greater than or equal to the lower bound. As in the exact match case, as each entry that matches the range predicate is found, its corresponding object is retrieved, further evaluated, and returned if it satisfies all predicate terms. If the last entry of a leaf page is processed and the upper bound has not been reached, the query follows the next pointer of the doubly linked entries to the right-hand neighbor and resumes sequential processing with the first entry. This continues until either the upper boundary, u, is reached, or the last leaf page has been processed.

Predicate using a set operator

A set predicate has the form:
attribute set_operator key_links where attribute has the type: link, array of link, or link vstrs.
The operator options for a set_operator are:
O_INTERSECT
O_NOT_INTERSECT
...

If the operators O_INTERSECT, O_SUPERSET, or O_EQUIVALENT_SETS are used, a B-tree index can be created on the attribute. The B-tree index can then be used to drive the predicate evaluation. Instead of scanning the entire class, the targets to be examined can be reduced by searching the B-tree index from key_links, reducing the time and resource costs because the number of links in key_links is generally much smaller than the number of links in the class.
When a query traverses a B-tree index, frequently referenced pages, such as the root page and its directly descendent interior node pages, are likely to remain in the buffer cache. As a result, the cost of b-tree overhead for a query includes a couple of node pages down the traversed path, and a list of leaf pages covered by the key values.


Query Usage of Indexes

Various types of queries use indexes differently.

Query with a single predicate term

Suppose that your predicate consists of a single predicate term, and that it is indexable. In this case, index pages are brought into memory and read sequentially on its leaf pages. If an index value satisfies the predicate term, then the data page for the corresponding object is fetched.
Query with terms concatenated only with AND Suppose you have a predicate such as:
( A and B and C and ... ) where A, B, and C... are "terms," such as color=="Red" or age>=65 .
In this case, the query terms will be read from left to right.
If none of the terms are indexable, then all objects will be fetched and evaluated in a single pass through the data pages.
If there is only one indexable term, then the index pages are brought into memory and read sequentially from its leaf pages. If an index value satisfies the indexable term, then the data page for the corresponding object is fetched, and the object is evaluated further using the rest of the predicate terms.
If there are multiple indexable terms, then the terms will be evaluated to determine which one to use. If any of the indexable terms uses the equals operator, then the first term using the equals operator, reading from left to right, is used. If none of the indexable terms use the equals operator, then the first term found, reading from left to right, will be used. (The reasoning for preferring the equals operator is
that it will likely produce fewer objects for evaluation.)
Once an indexable term is chosen, index pages for that term will be brought into memory and read sequentially. If an index value satisfies the predicate term, then the data page for the corresponding object is fetched, and the object is evaluated further.
Knowing that access paths are chosen with left-to-right, equality-preference logic, you can phrase your query to use the indexable term that you want. For example, suppose that you have an indexable term with an equality operator, such as (sex=='M'). To avoid having it used as the access path, you can rewrite this term as a range predicate, such as (sex >= 'M' and sex <= 'M'), and then move it to the right end of your predicate.

Query with terms concatenated with OR

If your query uses terms concatenated with the OR operator, then what happens is more complex. First
your query is converted to disjunctive normal form, which means that mathematical conversions are done so that the query is expressed in a left-to-right format such as:
( A and B and C ) or ( D and E ) or ( F ) ...
where A, B, C... are "terms" and groups like (A and B and C) are called "orterms".
If you write your query in this form to begin with, its components will be evaluted left-to-right per the following discussion. If your query has to be converted to disjunctive normal form, DeMorgan's rules and the distributive rule of boolean algebras will be applied, but the basic left-to-right ordering of elements in
your query is preserved as much as possible.
If any orterm lacks an indexable term, then the entire class extent will be walked, one object at a time, evaluating the query on each object (with shortcut optimization when an orterm is true or a term inside an orterm is false). In this case, all objects are traversed, because if all objects need to be evaluated, it is
faster to do it in one pass.
If each orterm has at least one indexable term, then the entire query is indexable, and an index is used to traverse each orterm in succession. This means that objects in each orterm are returned in ascending order with respect to the index attribute, and that all objects in the result set are not necessarily sorted in a particular order.
Within each orterm, there may be multiple indexable terms concatenated with AND. If so, the terms are evaluated to determine which one to use. This evaluation occurs as described above for a query with terms concatenated with AND. In each index traversal of each orterm, data pages for objects whose indexes satisfy the query are fetched for further evaluation.
Although the automatic index choices are made in a way that optimizes most queries, you can control the choice by phrasing your query so that your first choice of index appears in the left-most term of each "orterm." If you have a range expressed in two terms, such as x>=42 and x<=54, put these two terms on
the left.
Knowing these behaviors, you can customize your indexes and queries to your needs. To evaluate the impact of various query strategies, you can monitor disk activity with performance monitoring statistics. For further
information on statistics, see the chapter "Statistics Collection."

...
22 дек 04, 17:12    [1201458]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Андрей Леонидович
Guest
Уважаемый Alex.Czech !

Извините, но я Вам не верю. Из того, что Вы говорите, следует, что MS SQL - это не совсем СУБД. Не может этого быть.
22 дек 04, 17:19    [1201495]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
AI
... с которыми иерархические или сетевые организации данных справляются плохо


А что значит плохо?
Я утверждаю, что современные ООСУБД справляются с ними точно так же, как и реляционные. Правда производительность будет немножко ниже.


AI
Таблица может жить в виде "обычного набора записей"; может в виде индекса то есть принципиально иной организации данных, когда в блоках данных (страницах) имеется еще и деревообразующие структуры, указатели; может храниться в кластере - в одном и том же блоке хранятся данные нескольких таблиц (мастер и детали вместе); может храниться в секциях - фактически, в нескольких таблицах. Когда дело доходит до ОР свойств, то в дело вступают еще и адреса объектов. Поскольку есть наследование (версия 9 и выше), проблем с хранением потомков других типов нет. Сами данные в зависимости от типов хранятся в разных представлениях и, возможно, отдельно от основной части строки.


Действительно современный Oracle содержит средства в чем-то приближающие его к объектным СУБД. Тем не менее эти средства по своим возможностям уступают тому же FastObjects. Причем уступают не в функционале, а в элементарном быстродействии на обработке объектных данных. Положить то эти данные в Oracle так или иначе можно. Не стану зарекаться и говорить, что так будет всегда, возможно когда-нибудь Oracle и станет истинно объектно-реляционной системой, которая позволит разработчику самому выбирать способ размещения его данных в базе (в виде таблиц или в виде объектов с возможностью навигации по связям). Но вот в чем я уерен, так это в том что скрестить ежа с ужем никогда в полной мере не удастся, т.е. все равно разработчику нужно будет четко решить - либо объекты, либо таблицы - и затем уже использовать соответствующий его выбору инструментарий для разработки приложений.
22 дек 04, 17:25    [1201536]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Андрей Леонидович
Guest
Уважаемый Al !

Информационная система не сводится к максимально быстрому доступу на одну запись, как тут пропагандируется. Она всегда требует нерегламентированных запросов, с которыми объектные организации данных справляются хорошо. Именно поэтому и непонятно зачем нужны "Р"СУБД с туманной идентификацией и семантикой данных, и совсем без навигации.
Причем чем дальше читаешь высказывания специалистов на sql.ru, тем не понятнее. Если меня попросят (а если еще и заплатят !), я смогу объяснить зачем они нужны. Но почему это не может объяснить ни один их сторонник ?
22 дек 04, 17:25    [1201537]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alex.Czech
Guest
Андрей Леонидович
Уважаемый Alex.Czech !

Извините, но я Вам не верю. Из того, что Вы говорите, следует, что MS SQL - это не совсем СУБД. Не может этого быть.


Тем не менее это так. При отключенном режиме "auto update statistics" (который на промышленной базе рекомендуется таки отключать) статистики автоматически не пересчитываются. Хотите - верьте, хотите - нет. Возлагается на администратора или на maintenance plan
22 дек 04, 17:36    [1201615]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Alex.Czech
Guest
В свою очередь позволю высказать сомнение, что тот же Каше аналогичные системные цифры типа количества записей на уровне иерархии апдейтит при каждой операции записи, больно это накладно
22 дек 04, 17:42    [1201652]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Sp1Der
Member

Откуда: Санкт-Петербург
Сообщений: 39
Alexey Rovdo



AI
Таблица может жить в виде "обычного набора записей"; может в виде индекса то есть принципиально иной организации данных, когда в блоках данных (страницах) имеется еще и деревообразующие структуры, указатели; может храниться в кластере - в одном и том же блоке хранятся данные нескольких таблиц (мастер и детали вместе); может храниться в секциях - фактически, в нескольких таблицах. Когда дело доходит до ОР свойств, то в дело вступают еще и адреса объектов. Поскольку есть наследование (версия 9 и выше), проблем с хранением потомков других типов нет. Сами данные в зависимости от типов хранятся в разных представлениях и, возможно, отдельно от основной части строки.


Действительно современный Oracle содержит средства в чем-то приближающие его к объектным СУБД. Тем не менее эти средства по своим возможностям уступают тому же FastObjects. Причем уступают не в функционале, а в элементарном быстродействии на обработке объектных данных. Положить то эти данные в Oracle так или иначе можно. Не стану зарекаться и говорить, что так будет всегда, возможно когда-нибудь Oracle и станет истинно объектно-реляционной системой, которая позволит разработчику самому выбирать способ размещения его данных в базе (в виде таблиц или в виде объектов с возможностью навигации по связям). Но вот в чем я уерен, так это в том что скрестить ежа с ужем никогда в полной мере не удастся, т.е. все равно разработчику нужно будет четко решить - либо объекты, либо таблицы - и затем уже использовать соответствующий его выбору инструментарий для разработки приложений.


Вопрос в том, что работает лучше и надежнее: Надстройки на тот же Оракл, призванные добавить ему "объектности", или системы, изначально созданные объектными?

Возьмем, к примеру, танк, приделаем к нему все, чтобы заставить его плавать (со скоростьую узла 2 :) ) и начнем сравнивать с катером, который сразу был сделан для того, чтобы плавать... Как вы считаете, что из этого выйдет?
22 дек 04, 19:43    [1202085]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Терпеливый
Guest
Терпеливый
1) Какая именно статистика собирается по объектам?
Андрей Леонидович
Необходимая и достаточная статистика.

Терпеливый
2) Какие именно индексы используются (B-tree, bitmap, и т.д.)? Можно сразу с примерами в каких ООСУБД, какие индексы используются?
Андрей Леонидович
Нужные индексы.

Терпеливый
3) Как выглядит план выполнения запроса?
Андрей Леонидович
Симпатично выглядит.

Терпеливый
4) Какие этапы обработки запроса могут выполняться параллельно?
Андрей Леонидович
Все запросы выполняются параллельно.


На что Вы здесь после таких ответов рассчитываете? На понимание? На уважение?
22 дек 04, 20:34    [1202168]     Ответить | Цитировать Сообщить модератору
 Re: А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий  [new]
Андрей Леонидович
Guest
Уважаемый Alex.Czech !

Спасибо, что поддерживаете серьезный разговор.
Зря сомневаетесь. Только Cache здесь не причем. Я говорю про ОСУБД на MUMPS. Именно "апдейтит при каждой операции". И все прекрасно работает, но уже именно тщательной реализации MUMPS в Cache.

Итак, чтобы банально посмотреть сколько у нас Сидоровых (и т.п.) нужно делать запрос на языке SQL. В OEBS, как нам тут сообщили, конечные пользователи делают это с помощью discoverer и gldi. А в R/3 на MS SQL с помощью чего ?
Вам не кажется, что чем дальше, тем ужаснее ?
22 дек 04, 21:14    [1202206]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить