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

Откуда: Лужки
Сообщений: 5308
softwarer
Для этого я привёл пример, когда "производительность, а вовсе не психология".

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

тут нет противоречия. не шла речь о "психологии" в случаях использования врем. таблиц на MSSQL. ни в первом, ни во втором случае. это очевидно, просто прочитайте ещё раз.
21 апр 09, 18:23    [7094253]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
тридцать второй раз спрашиваю, что лично вам мешает хранить промежуточные результаты в оракловых GTT ? вроде ж 31 раз уже только с вашим участием перетерли ...


33ий раз можно перетереть, почему это неудобно. Глобальные временные таблицы есть и в MS SQL, но временные использовать проще.
21 апр 09, 18:30    [7094281]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
softwarer
SergSuper
softwarer
SergSuper
психология, не более

Не совсем так. Как минимум, "из стана MSSQL" часто шли утверждения, что разбиение сложного запроса на несколько стадий с хранением промежуточных результатов - необходимо для обеспечения производительности. Присутствующий здесь pkarklin в своё время говорил мне примерно так: да я видел такие запросы, что сервер только план для них будет строить несколько минут.

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

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

Вы сказали: психология, не более.
Я хочу опровергнуть это утверждение.
Для этого я привёл пример, когда "производительность, а вовсе не психология".

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

и я продемострирую Вашу любимую тенденцию
я написал: " не факт что он будет проще"
Вы меня процитировали: "в Оракле будет не лучше"
:)

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

если еще какая тенденцию всплыла - можете дальше иллюстрировать :))
21 апр 09, 18:32    [7094287]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Пилот Пиркс
Member

Откуда: Москва
Сообщений: 352
SergSuper
Пилот Пиркс
SergSuper
неужели Вам никогда не хотелось использовать данные, которые хранятся в массиве, прямо в запросе?

В оракле это возможно и без промежуточных таблиц. :)

или лучше так: а что такого есть в оракле что он позволяет делать это именно без промежуточных таблиц?

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

с другой стороны в TSQL нельзя в процедуре как параметр задавать выражение и pkarklin считает что только так и нужно

психология, не более

Дело не в психологии, а в технологии. Оракл так устроен, что ddl делает commit и требует довольно много серверных ресурсов. Поэтому оракловые разработчики научились обходиться без ddl-я. В частности придумали такие замечательные штуки, как pipelined function, селект из массива, глобальные временные таблицы.
21 апр 09, 18:39    [7094327]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Yo.!
SergSuper

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

тридцать второй раз спрашиваю, что лично вам мешает хранить промежуточные результаты в оракловых GTT ? вроде ж 31 раз уже только с вашим участием перетерли ...

да неудобно
допустим сейчас в каждой процедуре в среднем используют массива по три, в системе несколько десятков тысяч процедур
если бы GTT создавали только с их наименованиями путаница была бы
а потом процедуру удаляют - кто будет удалять лишние GTT?
поэтому человек думает: "да чё я тут буду новый объект в базе делать, согласовывать это дело, зафигачу-ка в массивчик"
ну и у меня есть некие ограничения связанные с технологией работы
21 апр 09, 18:50    [7094379]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Yo.!
Guest
pkarklin

33ий раз можно перетереть, почему это неудобно. Глобальные временные таблицы есть и в MS SQL, но временные использовать проще.

давайте, вот у нас только в последнем обсуждении было три потуги придумать задачу не удобную ораклу:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=619632&pg=42#6775119

с нетерпением ждем что-нить новое.
21 апр 09, 18:53    [7094390]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
SergSuper
например тут была на него жалоба
Да, там некрасиво вышло. Самому не понравилось.
21 апр 09, 18:54    [7094397]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Пилот Пиркс
SergSuper
Пилот Пиркс
SergSuper
неужели Вам никогда не хотелось использовать данные, которые хранятся в массиве, прямо в запросе?

В оракле это возможно и без промежуточных таблиц. :)

или лучше так: а что такого есть в оракле что он позволяет делать это именно без промежуточных таблиц?

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

с другой стороны в TSQL нельзя в процедуре как параметр задавать выражение и pkarklin считает что только так и нужно

психология, не более

Дело не в психологии, а в технологии. Оракл так устроен, что ddl делает commit и требует довольно много серверных ресурсов. Поэтому оракловые разработчики научились обходиться без ddl-я. В частности придумали такие замечательные штуки, как pipelined function, селект из массива, глобальные временные таблицы.

ddl для таблиц-переменных не нужен, так что не по теме, в mssql табличные функции есть, это аналог pipelined function, селект из массива - увы, как оказалось не из всякого, про ГВТ уже я выше написал

остаётся одна психология
21 апр 09, 18:55    [7094405]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Yo.!
Guest
SergSuper

если бы GTT создавали только с их наименованиями путаница была бы
а потом процедуру удаляют - кто будет удалять лишние GTT?

ну если у вас на коленках билды собираются и отсутствет документация можно поростенький SQL нарисовать отслеживающий одинокие таблички. минуты две займет.

SergSuper

поэтому человек думает: "да чё я тут буду новый объект в базе делать, согласовывать это дело, зафигачу-ка в массивчик"

а потом и начинается - он зафигачил массивчик, а процедурка теперь перекомпилируется на каждый чих, продакшен лежит, адб матюгается. ну и кому это порно в оракле нужно ?
21 апр 09, 19:01    [7094420]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
SergSuper
и я продемострирую Вашу любимую тенденцию
я написал: " не факт что он будет проще"
Вы меня процитировали: "в Оракле будет не лучше"

Отмечу принципиальный для меня момент: не процитировал, а обозначил тенденцию. Я согласен с тем, что предпочитаю.. максимизировать оттенки, иногда вплоть до утрирования. С моей точки зрения, при обсуждении качественных вопросов это делает беседу быстрее и понятнее. Однако, моя формулировка (Вы бросаетесь) подчёркивает, что это моё восприятие Ваших действий, не более. Фразу, скажем, "Вы говорили" я в такой ситуации не буду использовать, потому что она с моей точки зрения категорически неэтична.

SergSuper
каждый решает проблему как может, а все незнакомые способы считает ненужными - и это чистая психология

Не сказал бы. Разбиение запроса на части и временные таблицы - это "дополнительные сущности". Чтобы обосновать их необходимость, нужно некое достаточно объективное "лучше".

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

Наличие такого "объективного лучше" в Oracle под вопросом. Прямо измерить, к сожалению, трудно, но есть один момент. Насколько я могу судить, Oracle как СУБД в своём развитии в значительной степени опирается на опыт OEBS и других оракловых продуктов: те фичи, которые там нужны и первоначально реализуются "на коленке", в очередной версии появляются уже в составе СУБД. Следовательно, раз LMT до сих пор не появились - значит, этим продуктам они особо не нужны. То есть "умные дяди из оракла" посчитали, поднимет ли эта фича производительность их продуктов, и сказали "нет".

Таким образом, таки не психология. Во всяком случае, в первую очередь не психология.
21 апр 09, 19:07    [7094441]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
SergSuper
Member

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

SergSuper

поэтому человек думает: "да чё я тут буду новый объект в базе делать, согласовывать это дело, зафигачу-ка в массивчик"

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

а чё такое недоверие к любимой фирме? MS же смогла сделать что бы процедуры не перекомпилились, думаю и ораклу будет под силу
21 апр 09, 19:16    [7094469]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
SergSuper
Member

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

Наличие такого "объективного лучше" в Oracle под вопросом. Прямо измерить, к сожалению, трудно, но есть один момент. Насколько я могу судить, Oracle как СУБД в своём развитии в значительной степени опирается на опыт OEBS и других оракловых продуктов: те фичи, которые там нужны и первоначально реализуются "на коленке", в очередной версии появляются уже в составе СУБД. Следовательно, раз LMT до сих пор не появились - значит, этим продуктам они особо не нужны. То есть "умные дяди из оракла" посчитали, поднимет ли эта фича производительность их продуктов, и сказали "нет".

Мне кажется это на самом деле сложно сделать. Есть объекты базы и объекты языка и по сути это разные вещи. В том же TSQL это сделано не совсем чисто - таблица-переменная всё-таки создаёт временную таблицу, которая в свою очередь является обычной таблицей, но в специальной БД, и даже пишутся транзакции в лог, но только не комитятся. В оракле где система еще сложнее это пока приемлемым способом не сделать.
Но я не сомневаюсь что это всё равно будет сделано и в оракле, вопрос времени. GTT ведь тоже вроде не сразу появились.

Фича кстати нужна совсем не для поднятия производительности
21 апр 09, 19:29    [7094508]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
SergSuper
Мне кажется это на самом деле сложно сделать.

Не спорю. Но за последние годы сделано много гораздо более сложных вещей. Тот же query rewrite. Поэтому имхо фичу считают "не настолько нужной, чтобы делать".

SergSuper
В оракле где система еще сложнее это пока приемлемым способом не сделать.

В оракле это не один год как сделано. В топике была подсказка: with умеет материализовать промежуточные результаты, то есть по сути создаёт LTT. Растянуть время её жизни на процедуру - вряд ли так уж сложно.

SergSuper
Но я не сомневаюсь что это всё равно будет сделано и в оракле, вопрос времени.

Ну, я не сомневаюсь, что рано или поздно кто-нибудь сделает возможность указывать сиквенс дефолтом для ключа таблицы. Но время что-то идёт и идёт...
21 апр 09, 19:49    [7094565]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Yo.!
Guest
SergSuper

а чё такое недоверие к любимой фирме? MS же смогла сделать что бы процедуры не перекомпилились, думаю и ораклу будет под силу

если бы МС смогла, может и доверие появилось бы, а поскольку и рекомпиляции и насилование и без того узкого темпдб осталось, то ни доверия нифига не внушаетъ. да и нафига козе боян по прежнему актуален, пролетающие сквозь процедуры времянки - уж совсем чуждо оракловой строгой типизированности.
21 апр 09, 19:49    [7094566]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
barrabas
Member

Откуда: от махмуда
Сообщений: 10530
в оракле можно в коллекциях спокойно хранить промежуточные результаты, пользовался не раз для ускорения - разделения большого запроса с кучей фильтров.
ничем не отличается от программирования на ооп языке, создаешь класс/структуру потом коллекцию этих объектов.
Удобство мс временных таблиц налицо только в скриптах которые нужно быстро написать и выполнить, а для написания хранимок нужно подходить более фундоментально - домены, описать типы, определится и интерфейсом пакетов.
кстати в оракле есть пакеты - это огромный плюс, жалко нет наследования в них.
21 апр 09, 22:28    [7094962]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
AAron
Member

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

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

это не в плюс и не в минус. но факт есть факт.

По мне так дешевле было бы купить еще памяти, чем пару месяцев работы программиста. благо она стоит сейчас не так дорого.
22 апр 09, 02:27    [7095324]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
SergSuper
вобще странно - один хамит, а претензии к тому кто ему замечание делает

А кому я нахамил? Я назвал вещи своими именами. Если в языке программирования в качестве параметров процедур нельзя использовать вычисляемые выражения - то это хреново. Давайте представим, что такой косяк присутсвовал бы например в C?
22 апр 09, 08:13    [7095482]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
SergSuper
что касается FreemanZAV то это замечание по савокупности, например тут была на него жалоба, но я уже поздно сообразил

Он пошутил, я пошутил. Чего не скажешь в шутейном разговоре (С)
22 апр 09, 08:26    [7095502]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
а поскольку и рекомпиляции и насилование и без того узкого темпдб осталось, то ни доверия нифига не внушаетъ.


Слушайте, уже надоел этот фетишизм с выделенным. Не хотите доверять (не читал, но осуждаю) - не надо. Другие могут подумать с Ваших слов что так на самом деле. :) Есть рекомендации (официальные) что может приводить к рекомпеляции и что может повысить производительность tempdb. Очень замечательно у Вас получается из любой статьи KB, дающей рекомендации по производительности, делать выводы со знаком "-".

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


И чем GTT более "типизированы" в Oracle, чем LTT в MS SQL?!
22 апр 09, 08:46    [7095550]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
дддддд
Guest
И все же хотелось бы увидеть пару примеров, где нельзя обойтись без временных таблиц в MS SQL.
Затем перевести эти процедуры в Оракл и посмотреть, можно ли в Оракле обойтись без временных таблиц.
22 апр 09, 09:30    [7095707]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
softwarer
Member

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

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

Вопрос, однако, не только в этом. Добавление памяти вовсе не обязательно увеличит быстродействие сервера. Реально оно может уменьшиться - если узким местом являются процессоры.
22 апр 09, 09:37    [7095739]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
дддддд
И все же хотелось бы увидеть пару примеров, где нельзя обойтись без временных таблиц в MS SQL.
Затем перевести эти процедуры в Оракл и посмотреть, можно ли в Оракле обойтись без временных таблиц.


Разве речь шла о том, что без них нельзя обойтись?!
22 апр 09, 09:43    [7095782]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
ддддддд
Guest
pkarklin
дддддд
И все же хотелось бы увидеть пару примеров, где нельзя обойтись без временных таблиц в MS SQL.
Затем перевести эти процедуры в Оракл и посмотреть, можно ли в Оракле обойтись без временных таблиц.


Разве речь шла о том, что без них нельзя обойтись?!


Да, именно об этом и речь.
Утверждается, что MS SQL круче, потому что в нем есть механизм временных таблиц, а в Оракле его нет.
22 апр 09, 09:56    [7095919]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
barrabas
Member

Откуда: от махмуда
Сообщений: 10530
AAron
barrabas,

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

это не в плюс и не в минус. но факт есть факт.

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

ну так естественно, нужно понимать что делаешь, в моем случае кол-во записей не могло быть гиганским, в память я бы миллионы не стал запихивать . Для каждой проблемы нужно свое решение.
22 апр 09, 09:58    [7095935]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
barrabas
Member

Откуда: от махмуда
Сообщений: 10530
пакеты - основное преимущество pl/sql на конкурентами.
если придется переходить на другую БД, нужно будет переходить и на трехзвенку, бардак и процедур и функций ихмо - шлак.
Хотя в поскл глупые ограничения, например, нельзя объявив курсор на уровне пакета вернуть его результат в качестве рефкурсора, приходится дублировать код (я про случай если этот селект/курсор нужно использовать в нескольких процедурах).
22 апр 09, 10:07    [7096019]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8 9 10 .. 16   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить