Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 16   вперед  Ctrl
 Re: PL/SQL vs.Transact SQL  [new]
Зайцев Фёдор
Member

Откуда: Лужки
Сообщений: 5308
ASCRUS
И что же у них общего, что они двоюродные ? :)

производители аппаратных платформ
29 апр 09, 12:52    [7128351]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Supertank
Member

Откуда: Екатеринбург
Сообщений: 6
Господа, а вы заметили, что ваш спор уже давно перерос на личности и эмоциональное (личностное) восприятие продукта?
Уже давно эти конкуренты занимают долю рынка прямо пропорциональную тому сколько в продукте "громких" возможностей и неоднозначно интерпретируемых реализаций функционала, подаваемых как конфетку.
И к чему эти споры, что Oracle так хорош, потому что она заколачивает денег больше остальных или что MySQL настолько фигов, что был почти бесплатен, или что Sybase получил прибыль, потому что в нем супер-пупер возможности появились. Интересно вот что будет с тем же MySQL в будущем - покупка его ORACLE только на минус самому MySQL, хотя казалось бы - "ORACLE - да он из всего конфетку может сделать!". Как бы не так.
Я вот уже давно убедился, что и на бесплатных продуктах можно сделать замечательные решения и дешевые. Только кому это надо? Оказывается, только малому бизнесу - больше никому, потому что построено все на откатах и зависимости стоимости самой компании от стоимости используемых IT-технологий.
И как показывает практика, хорошо работающие системы бывают на разных продуктах и плохо работающие тоже бывают на базе этих же самых продуктов. Лучше хорошо разбираться в одном продукте, чем плохо в разных. Так что возьмитесь за что-нибудь одно.
А выбор и так понятен - хочешь работать на малый бизнес с серыми зарплатами и ушлыми директорами - учи PostgresSQL, MySQL. Хочешь на больших и толстых, у которых все по плану - учи ORACLE. Или T-SQL для всех остальных компаний "средней паршивости".
29 апр 09, 14:14    [7129044]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Supertank
Господа, а вы заметили, что ваш спор уже давно перерос на личности и эмоциональное (личностное) восприятие продукта?
...
Хочешь на больших и толстых, у которых все по плану - учи ORACLE. Или T-SQL для всех остальных компаний "средней паршивости".


Вы бы сами за собой понаблюдали... ;)
29 апр 09, 14:19    [7129074]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
ASCRUS

Ню ню. С учетом возможностей вышедшей 15 версии IQ, думаю кандидатом на похороны на рынке хранилищ данных явно может оказаться не Sybase ;) Я уж молчу насчет сравнения стоимости лицензий, сопровождения и требований к аппаратной части. ASE же пока IMHO отстает от Оракла, как минимум до тех пор, пока они не доведут до ума кластерную редакцию.

Ага, конечно, уже научились партиции, правда только range. Скоро научатся больше одного писателя на таблицу (или тоже научились?). Уважаемый, IQ, это скорее не СУБД, а альтернатива MOALP'у (кстати хорошая альтернатива), т.к. за пределеами своего применения неприменима вообще. :) Я не то, чтобы ругаю ее, мне она понравилась, но сравнивать "заточку" и универсальную СУБД считаю некорректным.

ASCRUS

P.S. Вообще сравнивать диалекты SQL у разных СУБД мне кажется неблагодарное занятие, ибо диалекты эти заточены под конкретные особенности сервера хранения и обработки информации.

Это с чего бы вдруг? Ну DDL, согласен, частично. Но DML тут при чем? Как мои SELECT'ы от особенностей хранения зависят??? Бред..

ASCRUS

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

И что? Мне вот в Оракле не хватает DB2'ашных CTE и убодного управления партициями. В DB2 нет MODEL. При чем тут особенности хранения? Просто не сделали и все. А так, принципиально ничего не мешает добавить.
29 апр 09, 15:58    [7129877]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Apex
Ага, конечно, уже научились партиции, правда только range. Скоро научатся больше одного писателя на таблицу (или тоже научились?). Уважаемый, IQ, это скорее не СУБД, а альтернатива MOALP'у (кстати хорошая альтернатива), т.к. за пределеами своего применения неприменима вообще. :) Я не то, чтобы ругаю ее, мне она понравилась, но сравнивать "заточку" и универсальную СУБД считаю некорректным.

Я сразу написал - в сфере хранилищ данных. Универсальный СУБД я не рассматриваю, это отдельная тема, кого считать универсальной БД и зачем они нужны ;)

Apex

Это с чего бы вдруг? Ну DDL, согласен, частично. Но DML тут при чем? Как мои SELECT'ы от особенностей хранения зависят??? Бред..

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

Apex
И что? Мне вот в Оракле не хватает DB2'ашных CTE и убодного управления партициями. В DB2 нет MODEL. При чем тут особенности хранения? Просто не сделали и все. А так, принципиально ничего не мешает добавить.

Принципиально производителям СУБД мешает добавить функциональность с других СУБД экономическая целесообразность на затраты и востребованность у пользователей. А вот теоретически да - никто не мешает добавить некую функциональность в новую версию сервера, это факт :)
29 апр 09, 16:14    [7130006]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Моряк с Ордынки
Member

Откуда:
Сообщений: 55
softwarer
Неизвестный
При переходе с TransactSQL на PL/SQL вспоминал, как хорошо была сделана документация по TransactSQL и MS SQL вообще по сравнению с документацией по PL/SQL и другой документацией Oracle.

Мне кажется, судить об этом стоит тем, кто одинаково и долго работает с обеими базами. Когда я начинал осваивать Oracle, электронной документации ещё не было (доступной), только бумажная. Потом появилась электронная, это было удобнее. Потом они перестроили документацию; я довольно долго ругался "всё не на месте, чёрт знает где и как искать", но привык и вполне с этим справляюсь. Когда делал проект на MSSQL - да точно так же "всё не на месте, чёрт знает где и как искать". Думаю, если бы работал долго - привык бы.



Да, кстати... Кто с чем работал долго, тот к тому и привык. Я вот вначале возмущался - типа трудно очень, а потом как-то свыкся... PL/SQL норм. язык, позволяет решать практически все, что необходимо прикладникам... Документации хватает, все можно посмотреть с примерами - на крайний случай сюда зайти. Где-то читал, IBM в свою DB2 планируют встроить поддержку PL/SQL - чем не признание? (хотя, возможно, не так понял).
29 апр 09, 21:59    [7131512]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Zhora
Member

Откуда: USA New York
Сообщений: 402
SergSuper
[quot Zhora]
...
С чего Вы решили что громоздкий запрос - это правильно?

В этом идея SQL, недостаток - если что-то не найдено при join - неясно где. Oracle прекрасно обходился без temp.tables много лет и обходится,
если больше подумать.
29 апр 09, 22:04    [7131523]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Zhora
Member

Откуда: USA New York
Сообщений: 402
А для удобства/избегания громоздкости можно/нужно использовать views (как модули)
29 апр 09, 22:09    [7131534]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
Временный теблицы нужны не для облегчения работы оптимизатора сервера, а для облегчения работы оптимизатора собственного мозга :). Сложный и длинный запрос очень тяжко писать, но еще тяжелее его потом переписывать/модифицировать по мере его жизни. Посему времянки по сути являются методом структуирования запроса. С ними очень удобно читать сам запрос, отлаждивать его по частям и в случае чего на порядок удобнее его модифицировать.
Со слов колег - ораклоидов, аналогичную роль времянкам, в оракле выполняет конструкция WITH.
29 апр 09, 23:37    [7131786]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
Ggg_old
Со слов колег - ораклоидов, аналогичную роль времянкам, в оракле выполняет конструкция WITH.

Да. С той разницей, что она не обязана материализоваться во времянки (хотя может это делать). А читаемости запроса помогает очень здорово.
30 апр 09, 00:03    [7131851]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Дикий Билл
Member

Откуда:
Сообщений: 9652
softwarer
Если мне не изменяет память, пару лет назад, когда в очередной раз прозвучало нечто подобное, я запустил поиск и показал, что подавляющее большинство тем MSSQL vs Oracle созданы mssql-щиками.
Нифига подобного!
30 апр 09, 04:06    [7132048]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Zhora
SergSuper
[quot Zhora]
...
С чего Вы решили что громоздкий запрос - это правильно?

В этом идея SQL, недостаток - если что-то не найдено при join - неясно где. Oracle прекрасно обходился без temp.tables много лет и обходится,
если больше подумать.
Это не идея SQL, это Ваша идея :)

Ну и насчет того что "прекрасно обходится" - я вот вижу что местами не очень прекрасно
30 апр 09, 09:59    [7132616]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Zhora
В этом идея SQL, недостаток - если что-то не найдено при join - неясно где. Oracle прекрасно обходился без temp.tables много лет и обходится,
если больше подумать.


Как бы Вы не думали, оптимизатор запросов (во всяком случие в MS SQL) может приянть решение использовать "темповые таблицы" (оператор Table Spool) для выполнения запроса. Если оптимизатор сам принимает такое решение, т.е. не может обойтись без сохранения промежуточного результата, то почеу Вы счиаете, что явное использование времянок - это "меньше думать". Есть ли аналог такого оператора в Oracle?
30 апр 09, 10:20    [7132739]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Пилот Пиркс
Member

Откуда: Москва
Сообщений: 352
pkarklin,

Есть. В некоторых случая оракл создаёт свои времянки и удаляет их по окончанию запроса. Можно даже хинтом +MATERIALIZE заставить его это сделать принудительно.
30 апр 09, 10:55    [7132972]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Пилот Пиркс,

Понятно. Спасибо. В MS SQL, начиная с 2005 версии можно явно создавать планы выполнения (включая Table Spool оператор) и "назначать" их запросам с помошью хинта USE PLAN.
30 апр 09, 11:16    [7133105]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Favn
Member

Откуда:
Сообщений: 585
Моряк с Ордынки
PL/SQL норм. язык, позволяет решать практически все, что необходимо прикладникам...
Где-то читал, IBM в свою DB2 планируют встроить поддержку PL/SQL - чем не признание? (хотя, возможно, не так понял).
Все правильно, в июне выйдет DB2 9.7 с поддержкой PL/SQL. Коротко - IBM подкинула денег EnetrpriseDB, которая есть платный PostgresSQL, и лицензировала у них "технологию совместимости с Ораклом". То есть DB2 теперь сможет работать как этакий навороченный PostgresSQL
А частичная совместимость с Оракловским SQL типа "connect by" есть и сейчас.
Правда, это не признание сильномогучести и универсальности PL/SQL, которая при наличии Java+SQLJ в DB2 не очень-то и нужна - Java все равно поуниверсальнее будет. Скорее, это признание распространенности Оракла и нормальное желание оттяпать у него часть рынка ;)
30 апр 09, 13:08    [7134032]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Favn
Member

Откуда:
Сообщений: 585
Ggg_old
Со слов колег - ораклоидов, аналогичную роль времянкам, в оракле выполняет конструкция WITH.
Если речь про CTE - эту роль она выполняет везде, где поддерживают SLQ3 - в т.ч. и в SS 2008 :) Но только в рамках одного запроса. Зато, в отличие от "ручного" формирования времянок, позволяет оптимизатору работать эффективнее, например используя распараллеливание внутри запроса.
30 апр 09, 13:12    [7134052]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Favn
Если речь про CTE - эту роль она выполняет везде, где поддерживают SLQ3 - в т.ч. и в SS 2008 :)


SS2005 тоже.
30 апр 09, 13:21    [7134144]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
aZm
Member

Откуда:
Сообщений: 2357
кстати, коллеги - а outline это оракловая примочка или оно есть и в mssql?

а то тут use plan упоминался, который, по идее, нечто схожее.

---
Ceterum censeo NATO esse delendam!
30 апр 09, 16:16    [7135240]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
hoarfrost
Member

Откуда: Волгоград
Сообщений: 438
rainurka
Хотелось бы услышать мнение людей, переходивших с MS SQL SERVER-а на Oracle, какие они при этом испытывали трудности при написании ХП.

Привет!
Говорю как перешедший на Oracle 9i с MSSQL 2000, и теперь вынужденно разрывающийся между двумя СУБД различных версий как по администрированию, так и по программированию.

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

Поначалу напрягало то, что временные таблицы должны быть созданы в схеме, а не как в MSSQL - в виде переменных. Но после того, как пару раз при перекомпиляции PACKAGE-а Oracle сказанул "парень, да у тебя эта временная таблица с другой структурой, а не с тем, что ты от неё хочешь", могу только сказать большое спасибо разработчикам Oracle Database за то, что они сделали именно так. Иначе, быть может пришлось приезжать ночью и в страшном цейтноте искать ошибку, начиная с трассировки клиентской части.

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

Если говорить кратко - то это как семёрка BMW и семёрка АвтоВАЗ-а. И там, и там - семёрка, руль и четыре колеса, однако же...
2 май 09, 14:44    [7138182]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Йцун
Guest
hoarfrost
Очень много деталей, который приводят к тому, что на Oracle - работает всегда и везде, а на MSSQL - не совсем всегда и не совсем везде.

Одну такую деталь я знаю: exception when others then null
Идиотов везде хватает, не обольщайтесь
4 май 09, 03:52    [7140670]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
Zhora
Когда мне пришлось переходить с Oracle на Sybase я тоже понял эту Sybase/MSSQL T_SQL технику (разбиеие запроса на ряд мелких с temp tables
в качестве хранителя проежуточных результатов базирующихся на key-fiedls и затем вытаскивание остальных полей дополительным join с "маленькой" результирующей "key-fields" temp.table), которая говорит о слабости
оптмизатора и несколько отучает думать на "правильном" (все в одном выражении !) SQL.


Все-таки надо как-то стараться различать "какой-то Вася там понаписал" от недостатков СУБД. А то как-то нехорошо получается...
4 май 09, 13:51    [7142446]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
Supertank
А выбор и так понятен - хочешь работать на малый бизнес с серыми зарплатами и ушлыми директорами - учи PostgresSQL, MySQL. Хочешь на больших и толстых, у которых все по плану - учи ORACLE. Или T-SQL для всех остальных компаний "средней паршивости".


А так хорошо Ваш пост начинался, я даже почти прослезилась...
4 май 09, 13:55    [7142473]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Piper_inside
Guest
Меня вот в последнее время на таких запросах плющит

SELECT DEPTNO, JOB, COUNT(*)
  FROM EMP
 GROUP BY CUBE(DEPTNO,JOB);


SELECT COUNT(*) OVER (PARTITION BY DATE) cnt_by_date, a.*
   FROM TABLE
5 май 09, 11:32    [7146476]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Piper_inside,

и что?
5 май 09, 20:37    [7150059]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 16   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить