Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 11 12 13 14 15 16 [17] 18 19 20   вперед  Ctrl
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
Gt.
Guest
автор
Опять-таки повторюсь: "Когда ЭТО у вас было, а у нас не было, мы Вам жутко завидовали. Теперь это есть и у нас, так что мы уже ни капельки не хуже"


так в принципе поэтому я и протестую :)
то же самое что с памятью - кроме автоматического выбора плана, у оракла еще туча возможностей на эти планы повлиять, поэтому с "Теперь это есть и у нас" позвольте все же не согласится ...
9 апр 04, 18:29    [621936]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Дык, и я могу влиять на план - от полного его составления вручную до частичных подсказок (правда, повторюсь, на некоторые вещи влиять,увы, не могу)
9 апр 04, 18:32    [621950]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
Gt.
Guest
план в ручную как ? хотя бы кейвордс я поищу ...

хинты конечно хорошо, нада сравнить ... но по сути они просто обманывают оптимизатор и обсолютно песполезны если нада план закрепить.

+ materialized view, row level security и т.п. когда оптимизатор переписывает твой запрос, это тоже фичи именно оптимизатора.
9 апр 04, 19:02    [621987]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
c127
Guest
2 x

>А я думал, что аппаратуру предоставляет фирма, которая хочет пройти тест. Она же настраивает - оптимизирует, а TPC выступает в роли независимого контролера.

Вот именно, что "которая хочет", а как быть с теми, ктоторые не хотят? Денег жалко, например.

2 Merle

>MS именно так и делает. И его ограничения ни чуть не искуственнее других.

Т.е. ограничить число таблиц в запросе это по-Вашему то же самое, что не ограничить вообще. Сложно что-либо возразить.

Вы будете удивлены, но и Дейт и Кодд на этих книгах тоже кое-чему учились,

Источник? Я посмотрел "Введение в СУБД" Дейта, ссылок на работы Bernstaine или Gray там не нашел, хотя у Дейта ссылки разбросаны по всей книге, и я мог легко пропустить.

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

Буду читать. Но вполне возможно, что в оракле принципы изложенные Греем применяются потому, что еще раньше их изложил Кодд или еще кто. Я тут тоже иногда излагаю принципы, но это не делает меня классиком БД.

>С аргументами тут вообще бедулька, так что я стараюсь не выбиваться из общей картины.

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

>Ок, вот живой пример:
......
обратите внимание, что в плане подзапроса нет, оптимизатор заоптимизировал это дело напрочь, чем существенно упростил жизнь серверу. Какой-нибудь другой оптимизатор, кроме MS-овского так умеет?


Не заоптимизировал, а заменил запрос на эквивалентный, еще неизвестно лучшй ли из всех возможных. Там есть top 1 в первой строчке плана и order by salary ASC чуть позже, что в совокупности как раз дает требуемый min(). Поэтому говорить об облегчении жизни сервера еще рано.

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

Кстати операции типа top N плохо вписываются в концепцию SQL-я, а в абстрактной теории множеств приводят к парадоксам. Почитайте об аксиоме выбора. Это значит что будут проблемы в прикладных областях, основанных на теории множеств, и поэтому классики SQL-я top N в язык первоначально не ввели. То что MSSQL пытается свести классический корректный запрос к потенциально проблемному top N говорит не в пользу его разработчиков, даже если они были учителями классиков.

Еще есть примеры оптимизации?
10 апр 04, 00:24    [622224]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
Merle
Guest
Источник? Я посмотрел "Введение в СУБД" Дейта, ссылок на работы Bernstaine или Gray там не нашел, хотя у Дейта ссылки разбросаны по всей книге, и я мог легко пропустить.
Смешно.. ;)
Ради интереса, первый же список литературы на который я наткнулся в моем издании дейта (6е, 2000 год), после 21й главы имеет три ссылки на разные статьи Бернстайна и одну на статью Грея. Поймите, то, что Вы о них ничего не слышали, не делает их менее известными и заслуженными. Грей вообще премию тьюринга получил за вклад в исследования обработки транзакций.
Кстати, по поводу логгинга и оганизации данных в DB2 и MSSQL (и не только), если интересно, советую почитать С. Мохана, тоже довольно известная личность, правда он работает в IBM. По поводу уровней изоляции - Беренсона A critique of ANSI SQL isolation levels, и эту классическую статью опять-таки написали большей частью сотрудники MS.

Это Вы зря, нормальные бывают аргументы как с одной так и с другой стороны, причем довольно часто, просто нужно читать внимательнее.
За весь этот монстроидальный топик не было высказано практически ни одного нормального аргумента или претензии, все придирки совдятся к "Як москали наше пыво называют".
Единственная здравая мысль заключается в том, что СУБД надо выбирать исходя из опыта людей которым придется с этой СУБД работать.

Не заоптимизировал, а заменил запрос на эквивалентный, еще неизвестно лучшй ли из всех возможных. Там есть top 1 в первой строчке плана и order by salary ASC чуть позже, что в совокупности как раз дает требуемый min(). Поэтому говорить об облегчении жизни сервера еще рано.
Нет, не рано, а в самый раз. Оптимизатор избавился от одного лишнего сканирования таблицы, другие на это не очень способны.

К Вашему сведению у разных SQL серверов разные варианты эквивалентных запросов выполняются по-разному, то что есть лучший вариант для MSSQL сервера не обязательно лучший для оракла и наоборот. Возможно что оракл в данном случае подзапрос не выбросит, но вовсе не потому, что Вы подумали, а потому, что ему нет нужды так выкручиваться с подзапросами
Это все конечно верно, но Вы не поняли главного. Оракл, и все остальные известные мне оптимизаторы, будут выполнять два физических сканирования таблицы. Первый раз для внутреннего запроса, а второй для внешнего. MS овскому же оптимизатору хватает ума понять, что если внутренний запрос применить ко внешнему, то результат не изменится, и поэтому он не делает еще одного не нужного физического сканирования таблицы. Так что и Ораклу и любой другой СУБД нужно именно так "выкручиваться с подзапросами", чтобы лишний раз по таблице не елозить. И это безотносительно Ваших, довольно спорных рассуждений по поводу top.
10 апр 04, 11:03    [622333]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2gt
см. set forceplan on, option(force order,{loop|merge|hash} join), ({inner|left|right|outer} {loop|merge|hash} join), (index=Indexname).
т.е. в принципе статью BOL "SELECT (described)"
2c127
>Не заоптимизировал, а заменил запрос на эквивалентный, еще неизвестно лучшй ли из всех возможных
Ну, по крайней мере, на более оптимальный, чем с двумя просмотрами таблицы. Если есть примеры лучшей оптимизации - плиз в студию.
А про теорию... как показывает практика.... то, что в теориюю является совершенно ненужным и даже запрещенным, на практике оказывается весьма и весьма полезным. тут была когда-то тема по поводку ЕК vs СК. Как мне помнится, в теории СК не нужны, а вот на практике... На практике даже ROWID (или ROWNUM?) из Oracle может пригодится.
10 апр 04, 11:45    [622347]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
Gt.
Guest
автор
Это все конечно верно, но Вы не поняли главного. Оракл, и все остальные известные мне оптимизаторы, будут выполнять два физических сканирования таблицы. Первый раз для внутреннего запроса, а второй для внешнего. MS овскому же оптимизатору хватает ума понять, что если внутренний запрос применить ко внешнему, то результат не изменится, и поэтому он не делает еще одного не нужного физического сканирования таблицы. Так что и Ораклу и любой другой СУБД нужно именно так "выкручиваться с подзапросами", чтобы лишний раз по таблице не елозить. И это безотносительно Ваших, довольно спорных рассуждений по поводу top.


Oracle® Database Performance Tuning Guide
Subquery Unnesting

Often the performance of queries that contain subqueries can be improved by unnesting the subqueries and converting them into joins. Most subqueries are unnested by the query transformer. For those subqueries that are not unnested, separate subplans are generated. To improve execution speed of the overall query plan, the subplans are ordered in an efficient manner.

в оракле это есть уже в 7 версии в 1992 году :)
10 апр 04, 13:40    [622407]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
Gt.
Guest
2locky

посмотрел на This table lists the options available for join hints, query hints, and table hints in Microsoft® SQL Server™ 2000.
10 хинтов ну мягко говоря совсем не тянут на соревнование с оракловыми
http://download-west.oracle.com/docs/cd/B13789_01/server.101/b10752/hintsref.htm

set forceplan on не совсем то, он просто говорит в каком порядке джоинить,с его помощью можно повлиять разве что на простенький запросик ... а что делать с вложеными, юнионами и т.п. ?

так-что "Теперь это есть и у нас" на уровне ораклового оптимизатора 10 лет назад.
10 апр 04, 14:16    [622431]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Gt.
Often the performance of queries that contain subqueries can be improved by unnesting the subqueries and converting them into joins. Most subqueries are unnested by the query transformer. For those subqueries that are not unnested, separate subplans are generated. To improve execution speed of the overall query plan, the subplans are ordered in an efficient manner.

Если я правильно понял здесь написано что Оракл вложенный запрос часто заменяет на запрос с джоинами. Ну собственно странно было бы если б он это не умел. Вам же пытаются объяснить что MS-вский оптимизатор заменяет этот запрос на селект вообще без джоинов.

Gt.
посмотрел на This table lists the options available for join hints, query hints, and table hints in Microsoft® SQL Server™ 2000.
10 хинтов ну мягко говоря совсем не тянут на соревнование с оракловыми
...
так-что "Теперь это есть и у нас" на уровне ораклового оптимизатора 10 лет назад.

Я чё-то не понимаю какое отношение имеют хинты к уровню оптимизатору. Это типа как сравнивать качество автомобилей по качеству прилагаемого к ним набора гаечных ключей. По сути хинты как раз должны заставлять работать оптимизатор не так как он хочет.
12 апр 04, 11:09    [623516]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
c127
Guest
2 Merle

>Смешно.. ;)
Ради интереса, первый же список литературы на который я наткнулся в моем издании дейта (6е, 2000 год), после 21й главы имеет три ссылки на разные статьи Бернстайна и одну на статью Грея.


Действительно, есть по крайней мере одна ссылка (#21.18) на Грея с комментарием Дейта: "A sketchy but good overview and tutorial". Что в переводе означает: схематический, но хороший обзор и пособие.

Т.е. к фундаментальным работа по мнению Дейта не относится. Врядли Дейт учился по этой работе, а Вы утверждали именно это.

Еще там написано, что эта работа "Also available as IBM Research Report RJ2699 (September 1979)". Так IBM уважаемая фирма, я с этим не спорю.

У меня издание 1995 года, глава 21 называется Distributed Database and Client/Server Systems. Эта часть книги чисто техническая, к основам и теории отношения не имеет.

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

Абсолютно согласен. Я и пытаюсь выяснить чем именно люди заслужили известность и уважение тех, кто о них слышал.

>Это все конечно верно, но Вы не поняли главного. Оракл, и все остальные известные мне оптимизаторы, будут выполнять два физических сканирования таблицы.

1) Какие еще оптимизаторы Вам известны?
2) Как поступают другие известные Вам оптимизаторы в данной ситуации? Только поконкретней, если можно.

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

Неверно. Ему хватило ума заменить связывание таблиц на ничуть не более простую операцию ORDER BY. В приведенном плане стоит "Sort(ORDER BY:(Departments.dept ASC, ...", который почему-то упрямо игнорируется. Этой сортитовки в первоначальном запросе не было и она для выполнения запроса не нужна, поскольку достаточно только связывания таблиц и ORDER BY Departments.salary ASC.

Оптимизация свелась к тому, что вместо "лишнего" связывания появилась лишняя сортировка.

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

Как мы только что выяснили, MSSQL по таблице лишний раз все-таки елозит, выполняя дополнительный order by. Если Вы знаете как выполнить order by без сканирования таблицы, то будет интересно послушать.

А что касается моих рассуждений по поводу top, то может быть Вы сможете объяснить, почему такая полезная, простая и удобная операция первоначально в SQL-e отсутсвовала? Хоть это к делу и не относится, я привел top не как основной аргумент, а просто к слову пришлось.

Еще раз повторяю: если MSSQL-ю удобнее делать лишний order by + top, так флаг ему в руки. Но то что оракл делает по-другому, как это удобней ораклу, не есть аргумент, что оптимизатор MSSQL-а лучше оракла. (Merle>Какой-нибудь другой оптимизатор, кроме MS-овского так умеет?).

2 locky

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

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

А если Вы хотите убедиться, действительно ли план оптимальный (точнее неоптимальный), то перепишите данный запрос несколькими способами, сравните планы и если вдруг какой-то из них окажется лучше приведенного тут, то это будет доказательством того что MSSQL оптимизатор не построил оптимальный план.
13 апр 04, 03:43    [624977]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Живучая тема оказалась :) Извиняйте, но честно говоря мне кажется тут как то однобоко работа оптимизаторов обсуждается. Не только же разгребом подзапросов он занимается. Например, команда iAnywhere, которые постоянно обтачивают свой оптимизатор, считают, что он должен как минимум:
1. Проводить предварительную оптимизацию запроса на выявление и перепостроение избыточных условий, связей, подзапросов и т.д. В MSSQL это есть, в Оракле не знаю, в ASA это выведено на уровень SQL, т.е. можно даже посмотреть на SQL скрипт переработанного оптимизатором SQL (полезно в учебных целях).
2. В конце концов построение плана запроса сводится у оптимизатора к одной единственной задаче - понять, какой из планов займет минимальное время выполнения. Поэтому не грех при построение планов ориентироваться на характеристики железа - кол-во процов, памяти, скорость винтов. В ASA например, есть даже специальная команда ALTER DATABASE CALIBRATE, которая проводит серию испытательных тестов над винтами и привязывает сервер к их реальным характеристикам, а не усредненной гипотетической модели. Не так давно в ASA была добавлена фича по эффективной работе с RAID-ами, что есть good, СУБД должна сама различать, где физические устройства, а где логические массивы.
3. Неплохо при построении плана и выполнении запроса учитывать текущую нагрузку сервера, думаю все согласятся, что один большой и страшный запрос не должен увести сервер в даун относительно других пользователей. А это опять означает, что оптимизатору придется выбирать между скоростью выполнения запроса/выделением кэша/загрузкой процессора. MSSQL в этом плане как мне кажется прихрамывает, в ASA решили пожертвовать скоростью, что в принципе и понятно - будучи еще http сервером сложно обслуживать web-сервисы, находясь в дауне.
4. При разработке стратегии на выборку оптимизатору не грех подумать о том, чтобы она не мешала операциям записи. Для блокировочников эта целая сага о том что уже блокированно, что может быть блокировано, какие и у кого уровни изоляции и т.д. В ASA планы запросов вообще могут отличаться в зависимости от уровня изоляции сессии. В ее BOL вообще есть целая глава, в которой подробно описан механизм разработки стратегий в зависимости от различных условий и принципы механизма блокировок, где его первоочередная задача сводится к тому, чтобы блокировать минимально блокируя. Как ни странно, но в отличие от MSSQL в ASA нет постраничных блокировок, фактически только 2 уровня: ROWLOCK и TABLELOCK, причем ROWLOCK не тормозит при блокировке большого обьема записей и не кушает ресурсов, но позволяет блокировать только то, что нужно. У MSSQL все тоже неплохо, правда есть парочка подводных камней с блокировками, но все это обходится при граммотной проектировке БД.
5. Каждый оптимизатор должен быть этаким Ностардамусом - попытаться наиболее точно предсказать, сколько и чего будет обработано в запросе. В этом плане у ASA и MSSQL одинаковая стратегия - предсказывания основываются на статистике по полям таблиц и индексам. Статистика хорошая штука, но только когда она правильная. Здесь пути MSSQL и ASA разошлись в разные стороны - у MS нужно периодически обновлять статистику, в ASA статистика автокоррелируется после выполнения запросов, т.е. оптимизатор смотрит по плану запроса, что он предполагал и что получилось на самом деле и самостоятельно делает необходимые поправки в статистике. Это позволяет при резком изменении большого обьема информации в БД самостоятельно выровнятся (сначала будет приседание сервера, а потом обратное выравнивание).
6. Конечно если думать очень долго, то можно состряпать самый лучший запрос. Однако оптимизатору очень долго думать вредно, особенно когда он дело имеет с ХП - метод советской очереди не самый лучший метод для СУБД. В MSSQL эту проблему решили простейшим путем - планы запросов компилируются вместе с компиляцией ХП, в принципе оно и правильно - все равно статистику надо ручками обновлять, можно и ХП заодно перекомпилить. В ASA при компиляции чего бы то не было никакие планы запросов не строятся и не сохраняются (обуславливается очень динамическими особенностями ASA - глобальными переменными, областью видимости временных таблиц, 2-мя очень даже разными диалектами: TSQL и WatcomSQL, и т.д. Фактически при компиляции ХП ASA не проверяет даже существование использующихся обьектов). Чтобы решать насущные проблемы в ASA сделан эвристический анализатор (этакая примитивная нейросетка в СУБД). При запуске СУБД ХП и представления начинают компилиться по мере обращения к ним. Их байт-код с планами запросов сохраняется в специальном для этого отведенном кэше. Задача анализатора - отслеживать компилируемые планы запросов ХП, представлений и часто посылаемых клиентскими сессиями. Лучшие из них (то есть те, которые наиболее точно предсказали результат выборки, и наиболее эффективно выполнились), удостаиваются медали - им повышается приоритет и оптимизатору рекомендуется при построении запросов брать их за образец. Планы запросов, зачисленные в золотую лигу (безупречные с точки зрения ASA), становяться де факто для выполнения без работы оптимизатора, оно и правильно, раз он не может уже собрать более лучший запрос, чем есть в коллекции анализатора. Однако ничего в мире не вечно, поэтому периодически анализатор проводит проверку своих планов запросов на безупречность, передавая снова работу оптимизатору и сверяя по результатам, не пора ли план из коллекции отправить на пенсию. Такая модель работы позволяет снизить затраты на администрирование БД, что очень ценно для удаленных СУБД (я еще называю ASA "самонаводящейся СУБД"). Еще хочу добавить, что такая кропотливая работа эвристического анализатора заслуживает уважения, поэтому недавно команда iAnywhere сделала правильный шаг - добавила механизм сохранения результатов его работы в БД, что и правильно - теперь даже при перезапуске СУБД моментально восстанавливаются лучшие проверенные планы запросов и СУБД минует многие стадии "разгона".
7. Ну и последний пункт - это каждый оптимизатор зависит от самой функциональности СУБД. Всегда конечно хорошо, когда оптимизатор может подзапрос разрулить в обычное соединение, но согласитесь и неплохо, когда у программиста развязаны руки - например в ASA сейчас ввели LATERAL соединения, позволяющие описывать подзапросы с внутренним соединением, т.е. фактически из подзапроса ссылаться к таблицам родительского запроса (можно сказать форма EXISTS в секции FROM). Очень удобная штука для написания различных сложных запросов и главное план запросов получается гораздо эффективнее по сравнению с обычным подзапросом. Common Table Expression (виртуальные вьюверы в запросах и рекурсивные запросы) тоже совсем жизни не мешают. Ну и кол-во и функциональность опций. Например, в ASA на работу оптимизатора влияет достаточное кол-во опций БД, вплоть до того, что сессию можно увести в фоновый режим и там не спеша обрабатывать себе данные, никому не мешая. Ну и плюс физическая реализация алгоритмов: в MSSQL очень прикольно сделана работа движка запросов по индексам, для ASA индексы более второстепенно, акцент в первую очередь ставиться в сторону хэш-соединений.

Гм, в общем я долго говорил, а к мысли главной только подошел: работа оптимизатора как видим зависит от класса СУБД и ее задач. Я более чем Вас уверяю, что для задач Мелко-Среднего-Бизнеса (SMB), где БД-шка не превышает 50-70 гб и максимальное кол-во пользователей 50-70, лучше Sybase ASA не найти, так как эта СУБД неприхотлива, автономна, может работать удаленно и реплицироваться с СУБД любого производителя, не требует наличия сисадминов и довольно таки навороченна для своего класса. Для Enterprise классов наверное СУБД уже может себе позволить сразу выставлять повышенные требования к технической части и требовать наличие квалифицированного персонала. Но что меня удивляет, так это задачки на MSSQL или Оракле с 10-табличками и парой миллионов записей - неужели из за таких обьемов стоит огород городить с такими СУБД ? :)
13 апр 04, 08:01    [625028]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
AlTk
Member

Откуда: Волгоград
Сообщений: 124
клиентская лицензия на SQL Server стоит ~150-160, а на ASA ~180-190.
а за ~5000 для SQL Server можно прикупить нелимитированную лицензию на процессор.

ПС. про ASA я могу и ошибаться. поправьте, пожалуйста, если я не прав.
13 апр 04, 09:33    [625130]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Расклад цен Sybase Anywhere (взято с Sybase.com), цены одинаковые на 32/64 разрядные версии для платформ Windows, Unix, Solaris, Linux, Novell:
Sybase Anywhere 9.0.1 + 1 клиент. лиценция: 399$
1 клиентск. лицензия: +199$
8 клиентск. лицензий: +499$
10 клиентск. лицензий вместе с сервером: 999$

Безлимитная лицензия на 2 CPU вместе с сервером:
SQL Anywhere Server - 2 CPU License 9.0 for Windows : 2999$

Developer Edition freeware, просто качается и устанавливается.

P.S. У меня тут есть еще один забавный pdf на сравнение в решениях Small-Medium-Business СУБД ASA 8, MSSQL 2000 и Oracle 9i Standart Edition, там рассматривается стоимость владения для каждой СУБД. Документ правда малость устарел, так как уже в эксплуатации ASA 9-ой версии, но цены думаю особо не изменяются, можно считать, что просто возможностей прибавилось. Ну естественно документ был "заказан" от Sybase, поэтому ASA там смотрится выгодней всех. Хотя я честно говоря с ними в одном согласен - в плане сопровождения ASA выгодней всех, раз ее особо и сопровождать не надо. Я тогда после обеда постараюсь его выложить и ссылку дать.
13 апр 04, 11:10    [625357]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2ASCRUS
Борис, ты не прав! (С)
В MS SQL Server есть галочка на базе "Автообновление статистики"
13 апр 04, 12:42    [625560]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
Merle
Guest
Действительно, есть по крайней мере одна ссылка (#21.18) на Грея с комментарием Дейта: "A sketchy but good overview and tutorial". Что в переводе означает: схематический, но хороший обзор и пособие.

Т.е. к фундаментальным работа по мнению Дейта не относится. Врядли Дейт учился по этой работе, а Вы утверждали именно это.

Это была ссылка на одну из работ, на которую я наткнулся не пролистав и двух страниц. К тому же не надо передергивать, я не говорил, что Дейт учился у Грея по какой-то конкретной книге.
Мое мнение, поскольку я читал и того и другого и кое что еще, заключается в том, что Дейт - мальчик и дешевый популяризатор, к тому же не всегда внятный. Что косвенно подтверждается тем, что Грей, как и Кодд и Дийкстра премии Тьюринга были удостоены, в отличии от того же Дейта, который больше чужие идеи своими словами пересказывал, и то не всегда удачно.
Если премия Тьюринга для Вас не аргумент, то не знаю как Вас убедить, да и не очень хочется. Вообщем, как пишут в аннотациях к дешевым фентезюхам - "прочитайте - убедитесь сами" ;)

1) Какие еще оптимизаторы Вам известны?
Оракл и, отчасти, DB2.

2) Как поступают другие известные Вам оптимизаторы в данной ситуации? Только поконкретней, если можно.
Сканируют таблицу, берут результат, сканируют еще раз в поисках того же результата, затем фильтруют и возвращают. Стоимость двух сканирований одинакова.

Ему хватило ума заменить связывание таблиц на ничуть не более простую операцию ORDER BY.
Посмотрите на стоимость этого Order by - будете приятно удивлены.

Как мы только что выяснили, MSSQL по таблице лишний раз все-таки елозит, выполняя дополнительный order by.
Не знаю чего Вы там выяснили, на мой взгляд план сиквела гораздо оптимальнее. Естественно с учетом физической реализации логических оперторов каждого из серверов.
Переубедить Вас в этом не получется, да и не очень хочется.

А что касается моих рассуждений по поводу top, то может быть Вы сможете объяснить, почему такая полезная, простая и удобная операция первоначально в SQL-e отсутсвовала?
Первоначально в SQL'е вообще было 4 операции. Никаких min, max, ect. там и близко не было. TOP действительно не имеет смысла в отсутствии сортировки, но при наличии оной все очень логично в теорию вписывается.
13 апр 04, 17:48    [626660]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Борис, ты не прав! (С)
В MS SQL Server есть галочка на базе "Автообновление статистики"

Сильно она помогает жизни ? По моему любой опытный боец мускула уже на автопилоте отвечает на вопрос почему вдруг все стало тормозить одним из первых советов: обнови статистику, перекомпилируй ХП.

Даю обещанную ссылку на сравнительный анализ.
13 апр 04, 18:00    [626680]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
Comparer
Guest
Oeacle Standard Edition One is offered at US$4,995 per processor or with Named User Plus licensing US$149 per user (minimum five users).

по поводу анализа - это шутка ? или в сайбесе действительно есть дурачки которые считают что кто-то будет покупать Named User лицензии на 50 клиентов ?

оракл очень дорог, но за эти деньги ты получаешь и соответствующий продукт.
13 апр 04, 22:45    [626995]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Гм, Оракл наверное неплох и наверное действительно очень дорог. Однако данный сравнительный анализ прошу заметить идет только на решения Мелко-Среднего-Бизнеса, на большее, типа Enterprise этот документ и не претендует. Вот я и хочу выяснить у общественности насколько этот документ верен/не верен именно в этой области рассмотрения стоимости владения СУБД. Насколько оправдано использовать Оракл и MSSQL там, где спокойно справляются обычные СУБД, не рассчитанные на тысячи подключений и сотни гигабайт информации ? У MSSQL во всяком случае с решениями для мелкого бизнеса все в порядке - MSDE и в путь с песнями. Выше 2 гигабайт наверное начинается по забугорным понятиям планка среднего бизнеса. Тут уже MSSQL надо покупать. Про сопровождение, требования к персоналу и аппаратуре тоже забывать не стоит, все это реальные деньги, а если отбросить всякие лицензии, то это самые главные деньги, которые тратятся на СУБД в России.

Как итог получается, что тот же Оракл пытаются применять там, где ему не место. Расскажу вам некоторую сказку на ночь:
Решили как то на досуге отцы в N-ском городе, некоторую отрасль автоматизировать полностью. Как и любая бюджетная отрасль, собиралися деньги с хоббитов, то бишь народа местного, причем было все понятно и простенько: в районах города были участки, которые взнимали пошлины с бедных хоббитов, делая непонятно сложные начисления, но иногда давая субсидии, тоже непонятные, но приятные. Вся оплата контролировалася и под сальдо подбивалася. Вот такая к слову задача неказистая, но на самом деле сложная. Долго ли дело шло, коротко, но нашлася контора, которая взялась ПО такое написать. Перво-наперво обьявили они во всеуслышание, что будут писать на Оракле, потому как окромя него ничего и не слышали, а знают точно, что тока эта СУБД большие обьемы перемалывает. Как решение было принято, да на государственном уровне, стала та контора ТЗ сочинять, да почище чем я сказки пишу :) Базы на участках оказалось в среднем будут по 2-5 гигов в год прибавлять, так что обьемы как оказалось не страшные там были. Участки автономно себе работали, никого не трогали, каждый своей отчетностью отчитывался, а в районах и самом городе тока общая отчетность требовалася, называлась она еще аналитикой. Вот прикинули в фирме той (невод закинули), не хорошо получается Оракл в участках ставить то. То ли дорого выходит, то ли дешево, но нет у казны города столько денюшек, чтоб купить лицензий столько и мощных серверов, чтоб админов столько развести в краю. И решились они сети выделенные, проложить по всему городу и поставить на район по серверу. Ну а чтобы от нагрузочек, не дымилися сети волоконные, подоткнули до кучи Джавою, с ее технологией трехзвенною. И поехала и понеслася нелегкая .... Дальше придумаете сами вы ... Я кстати там был, мед пиво пил, по ушам текло, а в мозги вот так и не попало :)

P.S. Кстати на участки прекрасно по характеристикам ставился Sybase ASA, он вполне был в состоянии автономно без админов тянуть участки районов, выделенка бы конечно пригодилась для гетерогенной репликации с хранилищем данных на сервере района, причем тут уже дело вкуса: MSSQL, Oracle, Sybase ASE, Sybase IQ и т.д. Однако я еще раз убедился, что в России сначала выбирают продукт (из того, что знают причем), потом составляют ТЗ, потом чешут репы и думают как продукт подогнать под ТЗ и выделенные под проект деньги. Такая вот Россия матушка. Одно меня радует, в том городе N-ском вакансий на Oracle и Java прибавится, это неплохо для рынка местных вакансий, с этой точки зрения я всегда обеими руками ЗА :)
13 апр 04, 23:37    [627031]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
c127
Guest
2 Merle

>Первоначально в SQL'е вообще было 4 операции. Никаких min, max, ect. там и близко не было. TOP действительно не имеет смысла в отсутствии сортировки, но при наличии оной все очень логично в теорию вписывается.

top и в отсутсвии сортировки имеет смысл. Но даже если принять Ваше утверждение, то сортировка появилась почти сразу, а top лет через 20 после нее, в середине-конце 90-х. И совсем ниукда не вписывается. Удобная операция, но идет вразрез концепции. А вот сортировка вписывается очень хорошо.

>К тому же не надо передергивать, я не говорил, что Дейт учился у Грея по какой-то конкретной книге.

Вы говорили что "и Дейт и Кодд на этих книгах тоже кое-чему учились" (Merle). Пренебрежительный тон Дейта не похож на тон каким ученик разговаривает с учителем. К тому же мы нашли книгу Грея, по которой Дейт заведомо не учился.

Я прочитал некоторые из статей Грея (http://research.microsoft.com/~Gray/JimGrayPublications.htm) и Бернстайна (http://research.microsoft.com/~philbe/).

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

Бернстайн просто смешной парень. Те 2 статьи из последних, которые я посмотрел - явная отработка зарплаты, наукой там не пахнет. Его книга (http://research.microsoft.com/pubs/ccontrol/), которая учебник, а не монография, может и неплохая, если судить по совокупности сегодняшней макулатуры, но на хорошую не тянет. Например он постоянно смешивает стили, перескакивая с формального стиля на популярный, а это низкий класс. Формальные куски не завершены, к примеру начато и не зваершено описание паскалеподобного языка описания алгоритмов. Почитайте того же Дейта, у него все выдержано в одном стиле, либо же читателя специально предупреждают, что следующая глава носит неформальный характер. Это высокий класс, по крайней мере необходимое условие высокого класса.

>Мое мнение, поскольку я читал и того и другого и кое что еще, заключается в том, что Дейт - мальчик и дешевый популяризатор, к тому же не всегда внятный. Что косвенно подтверждается тем, что Грей, как и Кодд и Дийкстра премии Тьюринга были удостоены, в отличии от того же Дейта, который больше чужие идеи своими словами пересказывал, и то не всегда удачно.
Если премия Тьюринга для Вас не аргумент, то не знаю как Вас убедить, да и не очень хочется. Вообщем, как пишут в аннотациях к дешевым фентезюхам - "прочитайте - убедитесь сами" ;)


Вот свежий всгляд на творчество Дейта.

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

>1) Какие еще оптимизаторы Вам известны?
Оракл и, отчасти, DB2.


"Всех остальных" набролось пол-штуки (Merle>Оракл, и все остальные известные мне оптимизаторы...), по-моему недостаточно, чтоб делать глобальные заявления.

>c127> Только поконкретней, если можно.
Сканируют таблицу, берут результат, сканируют еще раз в поисках того же результата, затем фильтруют и возвращают. Стоимость двух сканирований одинакова.


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

>Ему хватило ума заменить связывание таблиц на ничуть не более простую операцию ORDER BY.
Посмотрите на стоимость этого Order by - будете приятно удивлены.


А что тут смотреть, стоимость сортировки N*log(N) или что-то около того, не понимаю чему можно удивляться. Или я чего-то не понял?

>Не знаю чего Вы там выяснили, на мой взгляд план сиквела гораздо оптимальнее. Естественно с учетом физической реализации логических оперторов каждого из серверов.

Вот оно. Это как раз то, что я Вам с самого начала твержу: "с учетом физической реализации логических оперторов каждого из серверов". Иными словами сравнивать "в лоб", как Вы предлагали, планы разных серверов глупо и следовательно приведенный Вами план аргументом в пользу MSSQL-а быть не может. Спор можно закрывать.

Все-таки встречаются аргументы в этой конфе, раз удалось Вас переубедить.
14 апр 04, 02:27    [627100]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
c127
Guest
2 ASCRUS

>Однако я еще раз убедился, что в России сначала выбирают продукт (из того, что знают причем), потом составляют ТЗ, потом чешут репы и думают как продукт подогнать под ТЗ и выделенные под проект деньги.

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

>можно даже посмотреть на SQL скрипт переработанного оптимизатором SQL

Как именно? Когда-то смотрел, теперь не могу вспомнить как.
14 апр 04, 02:54    [627102]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Как именно? Когда-то смотрел, теперь не могу вспомнить как.

Функция REWRITE. Например если в нее подсунуть следующий запрос:

SELECT REWRITE('
SELECT s.id, s.order_date
FROM sales_order s
WHERE EXISTS(
SELECT *
FROM employee e
WHERE e.emp_id = s.sales_rep and e.emp_id = 100)
'
)

то с учетом того, что в таблице sales_order есть FOREIGN KEY на таблицу employee, по которому и шла связь в запросе, ASA вернет следующим образом преобразованный запрос:

SELECT s.id, s.order_date
FROM sales_order s
WHERE s.sales_rep IS NOT NULL AND s.sales_rep = 100

Далее если посмотреть план этого запроса, то в нем будет INDEX SCAN на таблицу sales_order только по условию sales_rep = 100. В данном случае если те же действия проделать в MSSQL, то из за условия emp_id = 100 его оптимизатор все таки включит в план запроса поиск по индексу emp_id на таблицу employee, обьединив далее через внутренний INNER JOIN с sales_order по ее индексу на sales_rep. Такая разность планов ASA и MSSQL обьясняется тем, что ASA очень активно использует метаинформацию по структуре БД, информация по FOREIGN KEY, PRIMARY KEY, UNIQUE CONSTRAINT и UNIQUE INDEX довольно активно используются при построении плана запросов, в самой семантике WatcomSQL (те же KEY JOIN - соединения по FOREIGN KEY) и при блокировках. Так что на этой СУБД изначально граммотно спроектированная БД во многом гарантирует красивую работу движка при выборках и блокировках.
14 апр 04, 06:51    [627146]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
Merle
Guest
К тому же мы нашли книгу Грея, по которой Дейт заведомо не учился.
И о чем это говорит? довольно смешной аргумент. ж))

Те 2 статьи из последних, которые я посмотрел - явная отработка зарплаты, наукой там не пахнет.
Его зарплата и есть наука, так что....

Например он постоянно смешивает стили, перескакивая с формального стиля на популярный, а это низкий класс
Это не он.. ;) просто некоторые главы написаны не им, отсюда и смешение стилей, о чем честно и предупреждено.

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

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

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

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

А что тут смотреть, стоимость сортировки N*log(N) или что-то около того, не понимаю чему можно удивляться. Или я чего-то не понял?
Стоимость сортировки в примере в 4 раза меньше стоимости полного сканирования таблицы. Остальные сервера заставляют сканировать два раза MS - один. Относительная стоимость сканирования таблицы у разных серверов примерно одинакова.

Вот оно. Это как раз то, что я Вам с самого начала твержу: "с учетом физической реализации логических оперторов каждого из серверов". Иными словами сравнивать "в лоб", как Вы предлагали, планы разных серверов глупо и следовательно приведенный Вами план аргументом в пользу MSSQL-а быть не может.
Вы опять не так поняли.. :)) Я имел вииду как раз обратное, что не смотря на то что в лоб сравнивать по большому счету действительно нельзя, сравнивая не в лоб план MS гораздо уачнее.

Все-таки встречаются аргументы в этой конфе, раз удалось Вас переубедить.
Увы, ни меня, ни-кого либо другого..

Вот еще один спорный аргумент, если хотите. Качество оптимизатора можно оценить по количеству хинтов на запрос. Как показывает моя практика, у MS необходимость применять явные хинты в запросе возникает гораздо реже...
14 апр 04, 10:10    [627382]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
Comparer
Guest
2ASCRUS

сказка больно маркетингавая :(
считаем
итак разница на 2х головый сервер оракл (standart one) будет дороже на 2K - это 2 зарплаты среднего программера. теперь посчитаем сколько месяцев будет ручками реализовывать этот редний программер то что уже есть в оракле ...

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

короче цена оракла + супорт + спецы будет в любом случае дороже однако в результате вполне может оказатся дешевле даже в мелком бизнесе.
14 апр 04, 10:25    [627425]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
PL99
Member

Откуда: Moscow
Сообщений: 1367
Comparer
итак разница на 2х головый сервер оракл (standart one) будет дороже на 2K - это 2 зарплаты среднего программера. теперь посчитаем сколько месяцев будет ручками реализовывать этот редний программер то что уже есть в оракле ...

Насколько я понимаю, речь идет о простых OLTP БД для первичного ввода данных. Что же такое есть для этих целей в Oracle, и чего нет в ASA?
14 апр 04, 10:41    [627492]     Ответить | Цитировать Сообщить модератору
 Re: Что лучше? Оракул9i или MS SQL2000? И чем?  [new]
Comparer
Guest
не знаю что вырезано в standart one, но фору в 2 месяца легко покроет только pl/sql + java ...
14 апр 04, 10:46    [627517]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 11 12 13 14 15 16 [17] 18 19 20   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить