Сообщений в теме: 70

[megadeath]

Насчет того что становится лучше это еще вопрос. Эллисон слишком зажрался ИМХО.

Зажрался, это к чему? к ценам на софт, или же в отношении к инновациям?

[Банников Павел]

Интересно. А у MS Exchange Server могут быть какие-то преимущетсва и недостатки перед Ораклом? Сравниваете квадратное с кислым имхо.

Лотус конечно имеет расширенные функции работы с данными, но это не сервер СУБД вообще.

С таким же успехом можно спросить в чем преимущество и недостатки сибирских пельменей перед базукой ?

Смотрите пост ?1 в этой теме. Lotus-Domino vs MsSqlServer для данного проекта.

[tooshiba]

Постреляционная СУБД не подойдет?
CACHE называется.

[Yukon]

Оракл это как "Победа" вроде бы и марка известная и колес у нее четыре и движок имеется и даже ездить на ней можно. Но "Победа" это уже не машина, это уже раритет.

Не слишком ли котегорично?
Обоснования почитал бы с удовольствием.

"Победа" на сегодняшний день слишком тяжелая, неповоротливая и слишком прожорливая машина с очень слабым двигателем. ...и вам всё сразу станет ясно - почему "Победа" это раритет.

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

Для частного лица и в свое время она была слишком капризна.

[Pooh]

Насчет того что становится лучше это еще вопрос. Эллисон слишком зажрался ИМХО.

Зажрался, это к чему? к ценам на софт, или же в отношении к инновациям?

В общем направлении компании ИМХО.

[kukushka]

Я не пользовался в полной мере не Oracle ни MS SQL Server, но на мой взгляд первостепенной проблемой в реализации БД. Является ее концептуальная модель. Обясню почему. Есть у вас таблица допустим 999..N записей и вам нужно подсчитать сумму кокогото столбца. Разные СУБД сделают эту операцию за разное время. Но если сделать регистр(т.е. еще одну таблицу с одной записью) и хранить в нем значение этой суумы, изменять значение в зависимости от изменений в таблице. И в итоге у вас под рукой всегда будет нужное значение.

[4eburashka]

Скажу пару слов в пользу Oracle.
Работаю с ней более полтора года. Объем данных приличный (в некоторых таблицах переваливает за 80 млн, кол-во постоянно активных сессий ~40). При гармотном тюнинге и правильной индексации запросы с джойнами 3 разных таблиц выполняются за ~ 0,10 секунд.
Конечно многое зависит и от железа, но с большими объмами так может справлятся только Oracle.

P.S. - Ранее имел небольшой опыт с MS SQL Server 2000. При схожих задачах данная СУБД показывает производительность ниже.

[Бреславец]

Я не пользовался в полной мере не Oracle ни MS SQL Server, но на мой взгляд первостепенной проблемой в реализации БД. Является ее концептуальная модель. Обясню почему. Есть у вас таблица допустим 999..N записей и вам нужно подсчитать сумму кокогото столбца. Разные СУБД сделают эту операцию за разное время. Но если сделать регистр(т.е. еще одну таблицу с одной записью) и хранить в нем значение этой суумы, изменять значение в зависимости от изменений в таблице. И в итоге у вас под рукой всегда будет нужное значение.

>Есть у вас таблица допустим 999..N записей и вам нужно подсчитать сумму кокогото
>столбца. Разные СУБД сделают эту операцию за разное время.

Это точно, за разное время выполнится, да еще и результат выдатут
разный . Oracle выдаст результат на момент запуска отчета, MSSQL если не блокировать ВСЮ таблицу перед запуском запроса выдаст результат с учетом измененных в течении запроса строк(другими сессиями).

Кроме того, если не блокировать таблицу перед запуском отчета по ней, в случае если
другие сессии меняют строки, которые должен прочесть запрос отчета, то отчет в MSSQL повиснет пока не будут закоммичены измененные другой сессией строки.

На курсах по Oracle я иногда демонстрирую.

Запускаем
SELECT COUNT(*)
FROM some_large_table

Тут же, в другой сессии делаем UPDATE строки по этой таблице, и вышеприведенный запрос в MSSQL браво висит. В Oracle он выдает результат, который был в таблице на момент запуска отчета(как и должно быть , ведь отчет просят на какое-то время, а отчет может и не 5 минут работать).

Oracle многоверсионная СУБД. Нет манагера блокировок, сжирающеко ресурсы сервера
при большом кол-ве блокировок. Именно поэтому в MSSQL,Sybase применяются эскалации блокировок(строка-блок-таблица).
В Oracle, к примеру чтение строки не мешает update этой же строки другой сессией,
и наоборот(update не блокирует чтение).



H.I.M
если Oracle раритет, то почему же практически все банки(огромные базы банкоматов, с тучей транзакций) у нас используют его?
Все наши сотовые компании также юзают Oracle.
Ядро Oracle, первой коммерческой СУБД вылизано очень хорошо, и для серьезных клиентов(серьезных баз) это много значит. Надежность, производительность,
многоверсионность.


А вообще, хороша та база с которой умеешь работать.
На MSSQL также можно вести достаточно серьезные проекты.
На старых версиях этого делать было нельзя, до версии 6.5 он был слишком сырой и глючный.

Сообщение отредактировал Бреславец: 24.08.2005, 14:15:06

[megadeath]

На курсах по Oracle я иногда демонстрирую.

Запускаем
SELECT COUNT(*)
FROM some_large_table

Тут же, в другой сессии делаем UPDATE строки по этой таблице, и вышеприведенный запрос в MSSQL браво висит. В Oracle он выдает результат, который был в таблице на момент запуска отчета(как и должно быть , ведь отчет просят на какое-то время, а отчет может и не 5 минут работать).

А на курсах по Сиквел Серверу, какой пример? Коллега.

[yedyge]

Я не пользовался в полной мере не Oracle ни MS SQL Server, но на мой взгляд первостепенной проблемой в реализации БД. Является ее концептуальная модель. Обясню почему. Есть у вас таблица допустим 999..N записей и вам нужно подсчитать сумму кокогото столбца. Разные СУБД сделают эту операцию за разное время. Но если сделать регистр(т.е. еще одну таблицу с одной записью) и хранить в нем значение этой суумы, изменять значение в зависимости от изменений в таблице. И в итоге у вас под рукой всегда будет нужное значение.

это решается триггером к таблице. хотя это имхо немного искусственно.

>Есть у вас таблица допустим 999..N записей и вам нужно подсчитать сумму кокогото
>столбца. Разные СУБД сделают эту операцию за разное время.

Это точно, за разное время выполнится, да еще и результат выдатут
разный . Oracle выдаст результат на момент запуска отчета, MSSQL если не блокировать ВСЮ таблицу перед запуском запроса выдаст результат с учетом измененных в течении запроса строк(другими сессиями).

Кроме того <...>

на самом деле это называется уровнем изоляции транзакции, и многие СУБД, претендующие на серьёзость, обязаны реализовывать определённый набор уровней. это вовсе не свойство конкретно оракла или мссиквела.

[Бреславец]

на самом деле это называется уровнем изоляции транзакции, и многие СУБД, претендующие на серьёзость, обязаны реализовывать определённый набор уровней. это вовсе не свойство конкретно оракла или мссиквела.

Конечно. Только Oracle не блокирует таблицу для согласованного чтения.
И это его режим работы Oracle по умолчанию (см. выше пример с тем как update мешает
select'у в MSSQL).

Долго выполняющийся SQL запрос по таблице(таблицам) дает результат в Oracle
на момент своего запуска. БЕЗ ВСЯКИХ БЛОКИРОВОК набора от DML другими сессиями.

Чтобы получить тоже самое в MSSQL, Sybase и
большинстве других СУБД надо либо вручную блокировать ВСЮ таблицу перед SELECT отчетом, либо надо выставлять уровень изолированности, который тоже установит блокировки (строк, страниц, таблицы целиком) от DML операций .
Т.е. изолированность по чтению в большинстве СУБД реализуется через не то место, а именно блокировки DML операций.


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

Часто идут на компромис и не выставляют уровень изолированности, но при этом получают данные НЕ на момент запроса(а данные по отчету просили, к примеру, на 12:00 ).

Сообщение отредактировал Бреславец: 26.08.2005, 15:50:12