АазСУБД затачивается под ...
- a) Oracle - OLTP
--
Andrei Kriushin (Oracle8/8i/9i OCP DBA), RDTEX J.S.C.
Disclaimer: Opinions are of my own and not necessar(-il)y...

Dear Andrei,
я не сертифицирован как Oracle8/8i/9i OCP DBA и уже вряд ли буду - сфера интересов уже не та, - но работая (и разрабатывая) в Oracle, DB2 и MS SQL уже лет 10, а в SQL среде так уже лет 18, я позволю сильно не согласиться с Вами по позиционированию Oracle.

Oracle уже великолепно заточена под OLTP приложения, а новые возможности больше направлены на интеграционные и аналитические аспекты использования. Другими словами, Oracle сегодня являет собой пример универсальной СУБД, которая сильна и рынке OLTP, и на рынке BI. В частности, я рассматриваю Oracle как прямой конкурент Teradata на ее, Teradatе, рынке но с одной главной особенностью - возможностью совмещения аналитического и оперативного контуров управления компанией в одной базе.

Andrej, не сужайте область применения Вашего профессиаонального инструмента - ведь к Вам, как сертифицированному специалисту, прислушаются посетители форума.

Opinions are of my own only и вытекают лишь из моего личного опыта... Но готов дискутировать по этому вопросу.

Yours faithfully,
Pi

Ааз Piне сужайте область примененияНе для усугубления... Я уже высказался, что функциональность в каждой СУБД позволяет все .

Oracle (я про него больше знаю) - версионник, изначально с минимальным уровнем блокирования - это СТРАТЕГИЧЕСКОЕ решение, проведенное через весь код. В смеси DSS&OLTP уже есть эфф э кт.

Вот и я том же, только в другом порядке слов - эффэ кт есть только в смеси DSS&OLTP .

Я никогда при работе с одной записью или с кортежом, подчиненной одной записи (строки накладной и прочее), не видел никакого преимущества Oracle по сравнению с чистым блокировочником (ублюдочные версии MS SQL 6.5 и ранее не в счет - это уже глюкавость поставщика).

Все преимущества Oracle возникали, когда нужно было выбрать более одной записи - построить отчет, произвести аггрегацию и т.п. Все это в Oracle делается не так, как в Teradata - делается "на лету" прямо в том же наборе записей, без потери свойств OLTP.

Поэтому Oracle - СТРАТЕГИЧЕСКИ универсальная база, никак не чистая OLTP. На чем настаиваю.

Regards,
Pi

Андрей Прохоров

1) В компаниях с относительно длинной IT историей крайне редко встречается одна всеобемлющая OLTP система, из которой можно получить все необходимые данные для DW или даже DSS. Как правило исходных OLTP систем несколько и далеко не обязательно все на Oracle. В такой ситуации DSS поверх OLTP даже теоритически не позволяет получить всей необходимой информации.
2) С технической точки зрения совместить OLTP и DSS на базе Oracle сложно. Для Oracle DSS и DW - это start schema, со всеми вытекающми последствиями. На этом настаивает и официальная документация и литература. Можно поверить Кимбалу, который утверждает, что и на start schema можно легко строить OLTP системы, но верится слабо.

2. а. start schema - имелась в виду star schema? Так вот, отвечаю, сегодня для Oracle DW - это Oracle9i Data Warehousing Guide Release 2 (9.2)
What is a Data Warehouse?
A data warehouse is a relational database that is designed for query and analysis rather than for transaction processing.
А star ли это, snowflake, 3NF, materialized view - это детали реализации.
b. Под базой Oracle я понимаю не схему (SCOTT, к примеру), а именно базу (например, ORCL). А Вы? Мне кажется, что Вы как раз подразумевали именно первое - схему.

1. аггрегаты поверх работающей OLTP - это лишь часть общей DSS . К примеру, данные за позапрошлый год я могу вообще хранить в текстовом файле, но это не мешает мне аггрегировать данные оттуда в materialized view. Вы согласны?

АазНо мне не нравится, что Вы провоцируете меня на сравнение двух СУБД (для этого есть отдельный форум) и неявную рекламу Oracle.

Dear Andrij,
Вы в этой ветке - а ее сегодня очень внимательно читают в Украине, - высказали мысль, что Oracle заточен под OLTP .
Я утверждаю именно здесь, в ветке про Терадату, что Oracle - универсальная СУБД , и очень неплохо выглядит также в решениях с DW и DSS. И просил Вас это признать именно здесь, в этой ветке - Вы, в отличие от меня, сертифицированный специалист и к Вашему мнению отнесутся соответственно.

А само сравнение Teradata & Oracle здесь неуместно, Вы правы.

yours faithfully,
Pi

Константин Лисянский
То есть, Вы хотите сказать, что на базе данных OLTP, хранящей всю историю работы предприятия вы готовы посадить с десяток другой DSS-пользователей, которые будут шерстить всю базу с ног до головы тяжёлыми запросами с кучей джойнов и агрегаций, а в это время тысяча-другая OLTP-транзакций будут летать и не замечать, что кто-то тут пыжится в усилиях решить стратегические задачи.
А если какой-то пользователь сделает нечаянно cross join пары таблиц по десять миллионов записей, то это также никак не скажется на производительности транзакций.
Если это так, то снимаю шляпу перед Oracle и перед таким передовым подходом к построению хранилищ данных.


Уважаемый Константин!
0. Не отождествляйте моих слов с политикой компании Oracle. Я высказываю сугубо личное мнение.

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

1. Говоря об универсальности Oracle, я вовсе не имел в виду что компания Oracle предлагает всегда шерстить суммарные запросы поверх транзакционных. Но возможность такую дает. Приведу пример: я могу сделать materialized view, которые хранит аггрегированные данные для какого-то отчета (да, отчет - не OLAP, но не забывайте, что DW тестируются как по тестам TCP-H, так и TCP-R), которое будет обновляться [после каждой транзакции|по моей команде]. Так вот, в определенном релизе Oracle (имеется в виду Oracle Enterprise with Data Warehouse option) при попытке получить данные из исходной таблицы оптимизатор может подставить результаты из materialized view. Понятно, к чему это приведет - взгляните на результаты тестов TCP-R . Кстати, они именно из этой features Oracle и появились.

2. В проектах, в которых мне приходилось участвовать, аналитическое хранилище ставится на самом верху - на уровне холдинга. Практически во всех случаях хранилище строится средствами той СУБД , которая стоит и внизу. Основная причина - это персонал заказчика, точнее, его знания. Вы спросите, а причем тут универсальность Oracle? А при том, что проект хранилища на MS SQL - это одно, а проекты хранилищ на Oracle выглядят совсем по другому, во многом очень близко к тому, что Вы рассказываете про Teradata - комбинированное секционирование (т.е., с хэшированием), возможности MPP-архитектуры (shared-nothing), и многое другое. Вообще, выскажу утверждение, что начиная с версии 7.3, с которой я начал работать с Oracle, именно усовершенствований для DSS сделано заметно больше, чем в сфере OLTP.

3. Еще один пример - несколько киевских торговых сетей, работающих на СПРУТ, поторопились перейти на Oracle 9i по одной единственной причине - возможность аналитических запросов к standby database. Понятно, что standby можно держать только в той же СУБД, что и OLTP, но теперь резервный сервер лишь чуть усилили - и вуаля!

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

Truly yours,
Pi

OLAPMASTERПожалуйста покажи план запроса где у тебя при выборке с having ничего на диске не сортируеться. Очень интресно посмотреть.

Смотри здесь Убедил?

nkulikov И в Oracle это за отдельные деньги???

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