powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / PL/SQL vs.Transact SQL
25 сообщений из 395, страница 7 из 16
PL/SQL vs.Transact SQL
    #35960665
Зайцев Фёдор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUSИ что же у них общего, что они двоюродные ? :)
производители аппаратных платформ
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35960963
Supertank
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Господа, а вы заметили, что ваш спор уже давно перерос на личности и эмоциональное (личностное) восприятие продукта?
Уже давно эти конкуренты занимают долю рынка прямо пропорциональную тому сколько в продукте "громких" возможностей и неоднозначно интерпретируемых реализаций функционала, подаваемых как конфетку.
И к чему эти споры, что Oracle так хорош, потому что она заколачивает денег больше остальных или что MySQL настолько фигов, что был почти бесплатен, или что Sybase получил прибыль, потому что в нем супер-пупер возможности появились. Интересно вот что будет с тем же MySQL в будущем - покупка его ORACLE только на минус самому MySQL, хотя казалось бы - "ORACLE - да он из всего конфетку может сделать!". Как бы не так.
Я вот уже давно убедился, что и на бесплатных продуктах можно сделать замечательные решения и дешевые. Только кому это надо? Оказывается, только малому бизнесу - больше никому, потому что построено все на откатах и зависимости стоимости самой компании от стоимости используемых IT-технологий.
И как показывает практика, хорошо работающие системы бывают на разных продуктах и плохо работающие тоже бывают на базе этих же самых продуктов. Лучше хорошо разбираться в одном продукте, чем плохо в разных. Так что возьмитесь за что-нибудь одно.
А выбор и так понятен - хочешь работать на малый бизнес с серыми зарплатами и ушлыми директорами - учи PostgresSQL, MySQL. Хочешь на больших и толстых, у которых все по плану - учи ORACLE. Или T-SQL для всех остальных компаний "средней паршивости".
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35960983
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SupertankГоспода, а вы заметили, что ваш спор уже давно перерос на личности и эмоциональное (личностное) восприятие продукта?
...
Хочешь на больших и толстых, у которых все по плану - учи ORACLE. Или T-SQL для всех остальных компаний "средней паршивости".

Вы бы сами за собой понаблюдали... ;)
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35961308
Фотография Apex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUS
Ню ню. С учетом возможностей вышедшей 15 версии IQ, думаю кандидатом на похороны на рынке хранилищ данных явно может оказаться не Sybase ;) Я уж молчу насчет сравнения стоимости лицензий, сопровождения и требований к аппаратной части. ASE же пока IMHO отстает от Оракла, как минимум до тех пор, пока они не доведут до ума кластерную редакцию.

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

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

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

ASCRUS
Поэтому у кого то развита поддержка временных таблиц, у кого то наворочена работа с курсорами, у кого то развит язык хранимых процедур и есть поддержка массивов, и т.д. и т.п. IMHO тоже самое, что сравнивать мотоцикл с машиной - много общего, но вот руль имеет другую форму и управление газулькой по разному осуществляется ;)
И что? Мне вот в Оракле не хватает DB2'ашных CTE и убодного управления партициями. В DB2 нет MODEL. При чем тут особенности хранения? Просто не сделали и все. А так, принципиально ничего не мешает добавить.
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35961365
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ApexАга, конечно, уже научились партиции, правда только range. Скоро научатся больше одного писателя на таблицу (или тоже научились?). Уважаемый, IQ, это скорее не СУБД, а альтернатива MOALP'у (кстати хорошая альтернатива), т.к. за пределеами своего применения неприменима вообще. :) Я не то, чтобы ругаю ее, мне она понравилась, но сравнивать "заточку" и универсальную СУБД считаю некорректным.
Я сразу написал - в сфере хранилищ данных. Универсальный СУБД я не рассматриваю, это отдельная тема, кого считать универсальной БД и зачем они нужны ;)

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

ApexИ что? Мне вот в Оракле не хватает DB2'ашных CTE и убодного управления партициями. В DB2 нет MODEL. При чем тут особенности хранения? Просто не сделали и все. А так, принципиально ничего не мешает добавить.
Принципиально производителям СУБД мешает добавить функциональность с других СУБД экономическая целесообразность на затраты и востребованность у пользователей. А вот теоретически да - никто не мешает добавить некую функциональность в новую версию сервера, это факт :)
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35962111
Моряк с Ордынки
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerНеизвестныйПри переходе с TransactSQL на PL/SQL вспоминал, как хорошо была сделана документация по TransactSQL и MS SQL вообще по сравнению с документацией по PL/SQL и другой документацией Oracle.
Мне кажется, судить об этом стоит тем, кто одинаково и долго работает с обеими базами. Когда я начинал осваивать Oracle, электронной документации ещё не было (доступной), только бумажная. Потом появилась электронная, это было удобнее. Потом они перестроили документацию; я довольно долго ругался "всё не на месте, чёрт знает где и как искать", но привык и вполне с этим справляюсь. Когда делал проект на MSSQL - да точно так же "всё не на месте, чёрт знает где и как искать". Думаю, если бы работал долго - привык бы.


Да, кстати... Кто с чем работал долго, тот к тому и привык. Я вот вначале возмущался - типа трудно очень, а потом как-то свыкся... PL/SQL норм. язык, позволяет решать практически все, что необходимо прикладникам... Документации хватает, все можно посмотреть с примерами - на крайний случай сюда зайти. Где-то читал, IBM в свою DB2 планируют встроить поддержку PL/SQL - чем не признание? (хотя, возможно, не так понял).
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35962115
Фотография Zhora
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuper[quot Zhora]
...
С чего Вы решили что громоздкий запрос - это правильно?
В этом идея SQL, недостаток - если что-то не найдено при join - неясно где. Oracle прекрасно обходился без temp.tables много лет и обходится,
если больше подумать.
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35962120
Фотография Zhora
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А для удобства/избегания громоздкости можно/нужно использовать views (как модули)
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35962242
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Временный теблицы нужны не для облегчения работы оптимизатора сервера, а для облегчения работы оптимизатора собственного мозга :). Сложный и длинный запрос очень тяжко писать, но еще тяжелее его потом переписывать/модифицировать по мере его жизни. Посему времянки по сути являются методом структуирования запроса. С ними очень удобно читать сам запрос, отлаждивать его по частям и в случае чего на порядок удобнее его модифицировать.
Со слов колег - ораклоидов, аналогичную роль времянкам, в оракле выполняет конструкция WITH.
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35962272
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ggg_oldСо слов колег - ораклоидов, аналогичную роль времянкам, в оракле выполняет конструкция WITH.
Да. С той разницей, что она не обязана материализоваться во времянки (хотя может это делать). А читаемости запроса помогает очень здорово.
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35962389
Фотография Дикий Билл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerЕсли мне не изменяет память, пару лет назад, когда в очередной раз прозвучало нечто подобное, я запустил поиск и показал, что подавляющее большинство тем MSSQL vs Oracle созданы mssql-щиками.Нифига подобного!
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35962677
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZhoraSergSuper[quot Zhora]
...
С чего Вы решили что громоздкий запрос - это правильно?
В этом идея SQL, недостаток - если что-то не найдено при join - неясно где. Oracle прекрасно обходился без temp.tables много лет и обходится,
если больше подумать.Это не идея SQL, это Ваша идея :)

Ну и насчет того что "прекрасно обходится" - я вот вижу что местами не очень прекрасно
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35962727
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZhoraВ этом идея SQL, недостаток - если что-то не найдено при join - неясно где. Oracle прекрасно обходился без temp.tables много лет и обходится,
если больше подумать.

Как бы Вы не думали, оптимизатор запросов (во всяком случие в MS SQL) может приянть решение использовать "темповые таблицы" (оператор Table Spool ) для выполнения запроса. Если оптимизатор сам принимает такое решение, т.е. не может обойтись без сохранения промежуточного результата, то почеу Вы счиаете, что явное использование времянок - это "меньше думать". Есть ли аналог такого оператора в Oracle?
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35962837
Пилот Пиркс
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklin,

Есть. В некоторых случая оракл создаёт свои времянки и удаляет их по окончанию запроса. Можно даже хинтом +MATERIALIZE заставить его это сделать принудительно.
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35962883
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пилот Пиркс,

Понятно. Спасибо. В MS SQL, начиная с 2005 версии можно явно создавать планы выполнения (включая Table Spool оператор) и "назначать" их запросам с помошью хинта USE PLAN.
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35963303
Favn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Моряк с Ордынки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 все равно поуниверсальнее будет. Скорее, это признание распространенности Оракла и нормальное желание оттяпать у него часть рынка ;)
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35963308
Favn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ggg_oldСо слов колег - ораклоидов, аналогичную роль времянкам, в оракле выполняет конструкция WITH.Если речь про CTE - эту роль она выполняет везде, где поддерживают SLQ3 - в т.ч. и в SS 2008 :) Но только в рамках одного запроса. Зато, в отличие от "ручного" формирования времянок, позволяет оптимизатору работать эффективнее, например используя распараллеливание внутри запроса.
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35963341
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
FavnЕсли речь про CTE - эту роль она выполняет везде, где поддерживают SLQ3 - в т.ч. и в SS 2008 :)

SS2005 тоже.
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35963779
aZm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кстати, коллеги - а outline это оракловая примочка или оно есть и в mssql?

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

---
Ceterum censeo NATO esse delendam!
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35965143
hoarfrost
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
rainurkaХотелось бы услышать мнение людей, переходивших с MS SQL SERVER-а на Oracle, какие они при этом испытывали трудности при написании ХП.
Привет!
Говорю как перешедший на Oracle 9i с MSSQL 2000, и теперь вынужденно разрывающийся между двумя СУБД различных версий как по администрированию, так и по программированию.

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

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

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

Если говорить кратко - то это как семёрка BMW и семёрка АвтоВАЗ-а. И там, и там - семёрка, руль и четыре колеса, однако же...
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35966181
Йцун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hoarfrostОчень много деталей, который приводят к тому, что на Oracle - работает всегда и везде, а на MSSQL - не совсем всегда и не совсем везде.
Одну такую деталь я знаю: exception when others then null
Идиотов везде хватает, не обольщайтесь
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35966887
Фотография Кудряшка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZhoraКогда мне пришлось переходить с Oracle на Sybase я тоже понял эту Sybase/MSSQL T_SQL технику (разбиеие запроса на ряд мелких с temp tables
в качестве хранителя проежуточных результатов базирующихся на key-fiedls и затем вытаскивание остальных полей дополительным join с "маленькой" результирующей "key-fields" temp.table), которая говорит о слабости
оптмизатора и несколько отучает думать на "правильном" (все в одном выражении !) SQL.

Все-таки надо как-то стараться различать "какой-то Вася там понаписал" от недостатков СУБД. А то как-то нехорошо получается...
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35966903
Фотография Кудряшка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SupertankА выбор и так понятен - хочешь работать на малый бизнес с серыми зарплатами и ушлыми директорами - учи PostgresSQL, MySQL. Хочешь на больших и толстых, у которых все по плану - учи ORACLE. Или T-SQL для всех остальных компаний "средней паршивости".

А так хорошо Ваш пост начинался, я даже почти прослезилась...
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35968656
Piper_inside
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Меня вот в последнее время на таких запросах плющит

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SELECT DEPTNO, JOB, COUNT(*)
  FROM EMP
 GROUP BY CUBE(DEPTNO,JOB);


SELECT COUNT(*) OVER (PARTITION BY DATE) cnt_by_date, a.*
   FROM TABLE
...
Рейтинг: 0 / 0
PL/SQL vs.Transact SQL
    #35970505
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Piper_inside,

и что?
...
Рейтинг: 0 / 0
25 сообщений из 395, страница 7 из 16
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / PL/SQL vs.Transact SQL
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]