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


Замечу, что в PL/SQL сложности могут возникать не в изучении языковых конструкций, а в изучении механизмов работы БД Oracle, но если Вы работаете с БД Oracle, то эти самые механизмы работы с Oracle надо знать по-любому.
22 апр 09, 15:35    [7099343]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
Я бы топик закрыл вообще как несодержательный, основная цель которого спровоцировать флейм на тему очередной могучести оракла. На пять страниц текста ни одной конкретной проблемы или вопроса.
P.S. Деление объектов логики БД на пакеты как в оракле считаю хорошей вещью, жаль, что ее нет в других СУБД. Но без этого жить можно.
22 апр 09, 15:39    [7099379]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
Ggg_old
основная цель которого спровоцировать флейм на тему очередной могучести оракла.

"Караул, всюду масоны"

Если мне не изменяет память, пару лет назад, когда в очередной раз прозвучало нечто подобное, я запустил поиск и показал, что подавляющее большинство тем MSSQL vs Oracle созданы mssql-щиками. Объяснял я это тем, что ораклоидам не нужно создавать топики и что-то себе доказывать, они и так уверены.
22 апр 09, 15:42    [7099412]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
дддддд
Guest
softwarer
Ggg_old
основная цель которого спровоцировать флейм на тему очередной могучести оракла.

"Караул, всюду масоны"

Если мне не изменяет память, пару лет назад, когда в очередной раз прозвучало нечто подобное, я запустил поиск и показал, что подавляющее большинство тем MSSQL vs Oracle созданы mssql-щиками. Объяснял я это тем, что ораклоидам не нужно создавать топики и что-то себе доказывать, они и так уверены.


+1
22 апр 09, 15:43    [7099426]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
softwarer
Member

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

Мне кажется, судить об этом стоит тем, кто одинаково и долго работает с обеими базами. Когда я начинал осваивать Oracle, электронной документации ещё не было (доступной), только бумажная. Потом появилась электронная, это было удобнее. Потом они перестроили документацию; я довольно долго ругался "всё не на месте, чёрт знает где и как искать", но привык и вполне с этим справляюсь. Когда делал проект на MSSQL - да точно так же "всё не на месте, чёрт знает где и как искать". Думаю, если бы работал долго - привык бы.
22 апр 09, 15:47    [7099453]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Зайцев Фёдор wrote:

> а нельзя ли дать объяснение в доступной сишникам (к примеру) форме ?
> просто не совсем ясно, какую роль выполняет пакет - статического класса,
> пространства имён или что-то ещё

Пространства имён.

Posted via ActualForum NNTP Server 1.4

22 апр 09, 16:27    [7099808]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Ёш wrote:

> иногда массивы очень удобны, например:
>
> select a, b, c, d ... where array[a,b,c,d] <@ array[*10*,*20*,*30*,*40*];
>
> проще и короче чем
>
> ... where a = *10* or b = *10* or c = *10* or d = *10* or a = *20* or b = *20* or c = ...

Перепиши на таблицы, будет ещё проще.

select ...
....
where field < any (select fld2 from myvalues)

Posted via ActualForum NNTP Server 1.4

22 апр 09, 16:30    [7099843]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Dimitry Sibiryakov wrote:

> Если Вы таки считаете, что в классическом паскале всё требовалось
> запихивать в один исходник, так Вы таки тоже заблуждаетесь.

Всётаки требовалось. Факт. Но именно в классическом, Виртовском.

Posted via ActualForum NNTP Server 1.4

22 апр 09, 16:31    [7099857]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

softwarer wrote:

Кстати вот "тяжёлая артиллерия" защитников PL/SQL подтягивается.
Не, я всё, сливаюсь
Пусть PL/SQL будет самым великолепным языком программирования
в мире !

Posted via ActualForum NNTP Server 1.4

22 апр 09, 16:34    [7099885]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54849

MasterZiv

Всётаки требовалось. Факт. Но именно в классическом, Виртовском.

Мнда, за 15 лет многое забывается. Да и вряд ли на СМ был Виртовский
компилятор. Но декларация external и сборка из разный объектных файлов
там вроде бы наличествовала.

Posted via ActualForum NNTP Server 1.4

22 апр 09, 16:54    [7100085]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
дддддд
Guest
MasterZiv


Пусть PL/SQL будет самым великолепным языком программирования
в мире !


Аминь!
22 апр 09, 17:03    [7100162]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Zhora
Member

Откуда: USA New York
Сообщений: 402
rainurka
Favn, говоря SQL, имел ввиду, что выражение SELECT он и в T-SQL и в PL/SQL делает одно и тоже. а именно делает выборку из таблицы.

Даже это не так. В Орацле вы получите - состояние на момент старта select-a (by default - snapshot isolation) не учитывающee изменений в течении select time (что правильно и как бы предолагает "мгновенность" исполнения запроса), а в Sybase - смесь из разных моментов времени (by default - read committed), не отражающую ни состояние на начало selecta, ни на конец (!) и зависяшую от "пути" запроса (кто-то мог заблокировать тот или другой индекс например). Конечно если вы поставите isolation level 3 (B Sybase - T-SQL создатель , MSSQL-"плагиатор") "тормозя" других или snapshot isolation в MSSQL (2005) то по идее будет результат одинаков.

Надо бы иметь 2 select-a: один на начало (не учитывающий изменений "по
ходу дела", как Oracle, MSSQL 2005 snapshot isolation), a другой - на
конец ( учитывающий все (!) изменения "по ходу дела" , как Sybase dump, Oracle flashback query), но не такой как все еще сейчас в Sybase - ни то, ни се - результат mess в multiuser system и никто не видит этого (!).
28 апр 09, 19:30    [7125616]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Zhora
Member

Откуда: USA New York
Сообщений: 402
pkarklin
softwarer
Присутствующий здесь pkarklin в своё время говорил мне примерно так: да я видел такие запросы, что сервер только план для них будет строить несколько минут.


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

Когда мне пришлось переходить с Oracle на Sybase я тоже понял эту Sybase/MSSQL T_SQL технику (разбиеие запроса на ряд мелких с temp tables
в качестве хранителя проежуточных результатов базирующихся на key-fiedls и затем вытаскивание остальных полей дополительным join с "маленькой" результирующей "key-fields" temp.table), которая говорит о слабости
оптмизатора и несколько отучает думать на "правильном" (все в одном выражении !) SQL.
Sybase ASE 15 имеет оптимизатор AFAIK больше похожий на Oracle (позволяющий строить на выходе optrimizer-a "программу" более "конвейерного" типа ("проход SQL синтаксис дерева в глубину" а не "по уровням c хранением промежуточых реультатов в worktables") не требующий work/temp tables.
28 апр 09, 20:03    [7125715]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Zhora
Member

Откуда: USA New York
Сообщений: 402
Вот за что надо "набить морду" я думаю разработчикам, а затем все-таки
договориться и сделать ANSI standard, так это за почти полный бардак с именами, форматом функций (for example: substring - Sybase/MSSQL, substr - Oracle , Mid - Access, etc...) а ведь без них никуда.
28 апр 09, 20:19    [7125753]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Zhora

Когда мне пришлось переходить с Oracle на Sybase я тоже понял эту Sybase/MSSQL T_SQL технику (разбиеие запроса на ряд мелких с temp tables
в качестве хранителя проежуточных результатов базирующихся на key-fiedls и затем вытаскивание остальных полей дополительным join с "маленькой" результирующей "key-fields" temp.table), которая говорит о слабости
оптмизатора и несколько отучает думать на "правильном" (все в одном выражении !) SQL.
Sybase ASE 15 имеет оптимизатор AFAIK больше похожий на Oracle (позволяющий строить на выходе optrimizer-a "программу" более "конвейерного" типа ("проход SQL синтаксис дерева в глубину" а не "по уровням c хранением промежуточых реультатов в worktables") не требующий work/temp tables.

Вы не правы
Я лично использовал временные таблицы исключительно для того чтобы код был нагляднее и менее громозкий. Ну и для отладки иногда удобно смотреть промежуточный результат.
Если есть удобная вещь не понимаю почему надо её избегать.
С чего Вы решили что громоздкий запрос - это правильно?
28 апр 09, 22:02    [7125925]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Zhora
В Орацле вы получите - состояние на момент старта select-a

...

Надо бы иметь 2 select-a: один на начало (не учитывающий изменений "по
ходу дела", как Oracle, MSSQL 2005 snapshot isolation), a другой - на
конец ( учитывающий все (!) изменения "по ходу дела"


Эээ... Что-то с терминологией я Вашей путаюсь.... "По ходу дела", "не походу"... В MS SQL есть (существующий с незапямятных времен) дефолтный уровень изоляции RC, который в режиме блокирововчника используeт Shared Locks. Есть (в режиме версионности) READ_COMMITED_SNAPSHOT (<> SNAPSHOT TIL) при котором читающая транзакция не накладывает S локов и обеспечивается Statement Level Consistency. При SET TIL SNAPSHOT обеспечивается Transactional Level Consistency. Наконец, можно и грязь читать с NOLOCK. Какие еще Вам SELECTы нужны, непонятно...
29 апр 09, 08:40    [7126581]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
pkarklin
Member

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


Такой ерундой никогда в жизни не занимался. И, описанный Вами случай больше смахивает на попытку использования обходного варианта, там где можно заняться оптимизацией. А над Вашим "говорит о слабости оптмизатора и несколько отучает думать на "правильном"" - долго смеялся... Хотите поговорить на эту тему - welkaм с репро в студию.
29 апр 09, 08:43    [7126586]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
дддддд
Guest
Корпорация Оракл купила Субейз.
Я думаю это сделано для того чтобы похоронить Субейз и вместо него продвигать что-то вроде Oracle 10g.
29 апр 09, 09:05    [7126643]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
ддд, вы чего-то путаете. Oracle купила SUN. F Ынифыу отрапортовал о значительном росте прибылей в первом квартале этого года:
License revenue increased 14% year over year and 19% year over year in constant currency
Database license revenues increased 31% year over year
GAAP operating income up 57% to $56.9 million, representing operating margin of 21%
Non-GAAP operating income up 41% to $68.9 million, representing operating margin of 26%
GAAP EPS up 39% to $0.33, non-GAAP EPS up 25% to $0.49
Highest-ever quarterly cash flow from operations of $97.4 million

2009 First Quarter Results

Источник: http://www.sybase.com/detail?id=1063340
29 апр 09, 10:43    [7127245]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
дддддд
Корпорация Оракл купила Субейз.
Я думаю это сделано для того чтобы похоронить Субейз и вместо него продвигать что-то вроде Oracle 10g.

Вроде 1 апреля давно прошло ? :) Или заголовок Oracle buys Sun мы уже читаем как Sybase ? :)
29 апр 09, 10:44    [7127253]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
дддддд
Я думаю это сделано для того чтобы похоронить Субейз и вместо него продвигать что-то вроде Oracle 10g.

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

P.S. Вообще сравнивать диалекты SQL у разных СУБД мне кажется неблагодарное занятие, ибо диалекты эти заточены под конкретные особенности сервера хранения и обработки информации. Поэтому у кого то развита поддержка временных таблиц, у кого то наворочена работа с курсорами, у кого то развит язык хранимых процедур и есть поддержка массивов, и т.д. и т.п. IMHO тоже самое, что сравнивать мотоцикл с машиной - много общего, но вот руль имеет другую форму и управление газулькой по разному осуществляется ;)
29 апр 09, 10:54    [7127315]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
дддддд
Guest
А SyBase как-то связана с SUN?
или мне показалось в статье, что вместе с SUN купили и SyBase...
29 апр 09, 11:26    [7127577]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
дддддд
А SyBase как-то связана с SUN?
или мне показалось в статье, что вместе с SUN купили и SyBase...

В статье даже слова такого, как Sybase нет :) Ну а связь Sybase с SUN конечно есть, точно такая же, как к примеру с IBM или HP - производитель софта по любому связан с производителем аппаратных платформ как партнер.
29 апр 09, 12:17    [7128025]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Зайцев Фёдор
Member

Откуда: Лужки
Сообщений: 5308
ASCRUS
В статье даже слова такого, как Sybase нет :) Ну а связь Sybase с SUN конечно есть, точно такая же, как к примеру с IBM или HP - производитель софта по любому связан с производителем аппаратных платформ как партнер.

Sybase, SUN и MS - двоюродные партнёры ?
29 апр 09, 12:24    [7128106]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Зайцев Фёдор
ASCRUS
В статье даже слова такого, как Sybase нет :) Ну а связь Sybase с SUN конечно есть, точно такая же, как к примеру с IBM или HP - производитель софта по любому связан с производителем аппаратных платформ как партнер.

Sybase, SUN и MS - двоюродные партнёры ?

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