Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 [13] 14 15 16 17 .. 24   вперед  Ctrl
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
locky
Еще, из того что встречал - на кой-то хрен используется dbms_sql - где
надо и - что самое противное - где не надо.

Это уже что-то совсем странное. Execute immediate - бывает, но чтобы программист взвалил на себя такую кучу лишней работы, как "пользоваться dbms_sql без необходимости".... где вы таких программистов берете? Скажите им, чтобы больше не давали :)
19 июл 07, 17:10    [4411482]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
dmidek
Member

Откуда: Киев - Дортмунд
Сообщений: 122133
locky

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


Строго говоря, я бы не назвал это ошибкой. Это EXCEPTION - исключение -
исключительная ситуация, так как по умолчанию SELECT INTO возвращает
1 и ровно 1 значение. Трактуете ли Вы эту ситуации для Вашей прикладной
программы как ошибка или нет - зависит от того, как Вы ее обработаете.
Сообщение пользователю о том, что "Данных не найдено" - это одно
из самых частых пользовательских сообщений, появляющихся на экране.
Было бы логично обрабатывать его соответствующим исключением.
19 июл 07, 17:10    [4411484]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Да нет, логично вполне, что в переменную писать та ?
К тому же, хочешь получить 0 - поставь count, хочешь NULL - поставь min :)
19 июл 07, 17:11    [4411488]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

softwarer wrote:
> Это уже что-то совсем странное. Execute immediate - бывает, но чтобы
> программист взвалил на себя такую кучу лишней работы, как "пользоваться
> dbms_sql без необходимости".... где вы таких программистов берете?
> Скажите им, чтобы больше не давали :)
Им поздно что-либо говорить - они уже переучиваются на MS SQL (бедный
сиквел!).
А нашел... Дык - такие где угодно, от Канады до Парагвая :(

Posted via ActualForum NNTP Server 1.4

19 июл 07, 17:15    [4411532]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

dmidek wrote:
> Строго говоря, я бы не назвал это ошибкой. Это EXCEPTION - исключение -
> исключительная ситуация, так как по умолчанию SELECT INTO возвращает
> 1 и ровно 1 значение. Трактуете ли Вы эту ситуации для Вашей прикладной
> программы как ошибка или нет - зависит от того, как Вы ее обработаете.
> Сообщение пользователю о том, что "Данных не найдено" - это одно
> из самых частых пользовательских сообщений, появляющихся на экране.
> Было бы логично обрабатывать его соответствующим исключением.
Ну, если так посмотреть - тогда еще более-менее вяжется.
Хотя - для евангелиста сиквела - всё равно странновато :)

Posted via ActualForum NNTP Server 1.4

19 июл 07, 17:16    [4411540]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

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

Хотя - для евангелиста сиквела - всё равно странновато :)


А Вы на Евангилие не зацикливайтесь. Кроме Селко есть много других людей кароших
19 июл 07, 17:20    [4411581]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
locky
Вот этого то я и не понимаю.
Если TOO_MANY_ROWS - в принципе вполне логично и понятно (ибо нехрен в
скаляр пихать вектор), то NO_DATA_FOUND - как-то немного странно.

Странно, если не привыкли работать с исключениями. Но гораздо удобнее, нежели писать if sql%notfound после каждого select-а. Представьте себе, сколько бы "программистов" забывали это написать....
19 июл 07, 17:22    [4411602]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

softwarer wrote:
> Странно, если не привыкли работать с исключениями. Но гораздо удобнее,
> нежели писать if sql%notfound после каждого select-а. Представьте себе,
> сколько бы "программистов" забывали это написать....
Ну, не после каждого, надо сказать..
а по поводу "забывать" - как показывает практика - не забывают, токо
пишут всякую хрень, прости господи :)
Ладно, давайте закроем под-темку - дело привычки, на самом деле. Тем
паче - краткое пояснение я получил - меня оно вполне устроило.

Posted via ActualForum NNTP Server 1.4

19 июл 07, 17:39    [4411787]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
drev
Смотрите, я их не писал, я приводил пример частоты использования функционала.:)

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

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

Скажем, первое же, из того что Вы привели:

IF EXISTS (SELECT * FROM inserted 
           WHERE mgr=emp)
BEGIN
  ROLLBACK TRAN
  RAISERROR('САМ СЕБЕ НАЧАЛЬНИК',16,10)
  RETURN
END

Уж простите, но только идиот будет делать это триггером. Это самый что ни на есть обычный check constraint.

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

Собственно, получается довольно забавная логическая цепочка. Напомню, я говорил - "странное и сомнительное решение было выделить inserted и deleted без updated". Сейчас оказывается, что в результате получилась прорва идиотского кода. Имхо это подтверждает предположение о сомнительности решения.

В общем, пока что Вы успешно подтверждаете практическое отсутствие внятных задач для "new без old". Почти сто процентов примеров - кривой код, нуждающийся в улучшении.

P.S. К сожалению, не удалось вечером ответить по поводу парсеров, постараюсь выкроить время в течение дня.



1. Даже в приведенных кусках достаточно много смысла.

2. Давайте наконец разберём вопрос, нужно ли делать проверку "изменилось ли значение". Вы утверждаете


softwarer
Снова - грубая ошибка, приводящая к реальной потере производительности.



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

Разберём конкретный пример:

Есть таблица

Order_details 
(
   id int identity primary key,
   order_id int,
   product_id int,
   quantity int,
   total money,
   just_one_more_column int
)


И есть триггер на INSERT, UPDATE, который меняет значение поля total = quantity * dbo.price (product_id , order_id), где функция определяет цену продукта на дату заказа.

Вы ранее упоминали calculated fields. Вероятно, Вы имели ввиду computed columns. Это решение не всегда подходит. Во-первых, существуют ограничения на выражение для их подсчёта, например, в нём нельзя использовать query, во-вторых, даже если база поддерживает свойство PERSISTED для них, это всё-таки накладывает некоторые ограничения на их использование.

Возникает вопрос, какой из вариантов в среднем даст лучшую производительность:

1. Выполнять операцию только для тех строк, у которых новые значения колонок quantity, product_id , order_id отличаются от старых, как Вы предлагаете.

2. Выполнять операцию для всех строк.

Очевидно, что сравнение, которое, по Вашей логике скорее всего должно быть добавлено в условие WHERE, повлечёт за собой некоторые дополнительные расходы:

а) На получение информации о старом значении колонок, которая более ни для чего не нужна.
б) На выполнение самого сравнения.

Очевидно, что возможный выигрыш определяется вероятностью, что в процессе UPDATE изменялись только колонки, которые не требуют выполнения операции (в данном примере -just_one_more_column ). Т.е. решение "сравнивать всегда" - является не совсем корректным.

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

НО! Вышеизложенное есть лишь лирическое отступление на тему выбора алгоритма.

К счастью, мне в голову не придёт пользоваться предложеной Вами схемой

softwarer
Ладно, допустим, делаем в триггере. Как будет написан этот триггер? Правильно, (:old.A <> :new.A or :old.B <> :new.B), иначе опять же сделаем лишнюю работу (полезем менять данные сами на себя)


Я просто напишу так:
IF ( UPDATE (order_id ) OR UPDATE (product_id )  OR UPDATE (quantity ))

      UPDATE ....

Я надеюсь, последнее хотя бы немного снижает в Ваших глазах необходимость наличия updated?
20 июл 07, 06:20    [4413322]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
MElin
Member

Откуда: Йо-бург
Сообщений: 84
dmidek
Bogdanov Andrey
Gluk (Kazan)
меня больше не all_objects смущает а попытка поймать NO_DATA_FOUND при запросе который заведомо вернет (именно) 0 без всяких эксепшинов.
Гарантированно !!! Призначайтесь, где еще отсебятина.


К большому сожалению, такое действительно встречается довольно часто. Вот кусок реального кода (кем он написан - не знаю):

procedure pAssertAccount(p_id IN tAccount.account_Id%TYPE)
-- This procedure assert IN parameter to be valid account_id
is
   l_count   INTEGER;
begin
    select count(*) into l_count
      from tAccount where account_id = p_id;
exception
  when NO_DATA_FOUND then
     raise_application_error(-20101,'Unknown account_id = ' || p_id || ' provided ');
  when others then
         l_errCode := SQLCODE;
         l_errMsg := SQLERRM;
         raise_application_error(-20102, l_errmsg);
end pAssertAccount;

Этот код гарантированно бессмысленнен, но тот кто его писал, видимо считал, что что-то он проверяет.


Да. Это распространенная ошибка. Он конечно проверял наличие/отсутствие записи,
но забыл, что в данном случае нужно проверять условие if l_count = 0


Гы гы гы гы.
Я, кажется знаю автора данного кода. Было дело так - один "умный" перец начал осваивать ораклу после ... скажем так после sybase ;-)
И читать кайта.
В начале дошел до процедур и функций. И выделил проверку наличия записи в функцию. с помощью count(*) и проверкой потом через if.
потом дошел до главы "исключения". count(*) был убран.
Потом прочитав далее - нашел прямую рекомендацию - не пользовать екзепшены в качестве проверки наличия записи. типа большой оверхеад и все такое. count(*) вернулся на свое законное место, но проверки, видать, возвращать было влом.... Ну так и осталось.

к стати конструкция
select count(*) into l_count from tAccount where account_id = p_id and rownum = 1 тож как то лишена особого смысла ;-)
Если уж заморачиваться, то над писать как то так
select count(*) into l_count from ( select /*+FIRST_ROW */ from tAccount where account_id = p_id and rownum = 1 )
ИМХО ;-)
20 июл 07, 08:09    [4413414]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
drev
softwarer
Снова - грубая ошибка, приводящая к реальной потере производительности.

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


Ага, ту играем, тут не играем, а тут РЫБУ заворачивали ...
хорошая бизнес-логика, а уж сопровождаемая
20 июл 07, 09:54    [4413761]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
Gluk (Kazan)
drev
softwarer
Снова - грубая ошибка, приводящая к реальной потере производительности.

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


Ага, ту играем, тут не играем, а тут РЫБУ заворачивали ...
хорошая бизнес-логика, а уж сопровождаемая



а подробнее?:) Что Вы имели ввиду?
20 июл 07, 10:06    [4413828]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
drev
а подробнее?:) Что Вы имели ввиду?


я имею в виду, что ПО ВОЗМОЖНОСТИ ограничения задаваемые бизнес логикой должны быть четкие и прозрачные. Если для Иванова ограничение должно работать, а для Петрова нет - что то не так в консерватории. Соответственно схема должна проектироваться так, чтобы ПО ВОЗМОЖНОСТИ ограничения задавались констрейнтами и только в самом самом крайнем случае триггерами (и уж боже упаси никак не JOB-ами )
20 июл 07, 10:23    [4413966]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
Gluk (Kazan)
drev
а подробнее?:) Что Вы имели ввиду?


я имею в виду, что ПО ВОЗМОЖНОСТИ ограничения задаваемые бизнес логикой должны быть четкие и прозрачные. Если для Иванова ограничение должно работать, а для Петрова нет - что то не так в консерватории. Соответственно схема должна проектироваться так, чтобы ПО ВОЗМОЖНОСТИ ограничения задавались констрейнтами и только в самом самом крайнем случае триггерами (и уж боже упаси никак не JOB-ами )


По моему, у нас разное понимание не бизнес-логики, а просто логики.

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

В этом контексте Ваше высказывание, сопровожденное цитатой, характеризуется другой поговоркой: "в огороде бузина, а в Киеве - дядька" :)
20 июл 07, 10:38    [4414088]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
drev
1. Даже в приведенных кусках достаточно много смысла.

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

drev
Вы (судя по предыдущим постам) считаете, что проверку нужно делать всегда.

О, сколько интересных утверждений начинаются со слова "очевидно"...

drev
Вы ранее упоминали calculated fields. Вероятно, Вы имели ввиду computed columns. Это решение не всегда подходит.

Не всегда. Тем не менее, сочетание этой фичи с нежеланием запрашивать лишние данные из других таблиц практически не оставляет случаев, когда подобный подсчет в триггере без old будет оптимальным решением. Я не собираюсь утверждать, что "вообще не бывает", но считать достаточно частым случаем, чтобы аргументировать им "объединенную inserted"... не готов.

drev
Возникает вопрос, какой из вариантов в среднем даст лучшую производительность:

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

drev
Т.е. решение "сравнивать всегда" - является не совсем корректным.

Угу. Вы вдруг стали математиком и успешно доказали, что математический ноль не равен физическому. Я с этим согласен, но дельта ничуть не приближает нас к утверждению, "да, часто нужен только :new".

drev
Я просто напишу так:
IF ( UPDATE (order_id ) OR UPDATE (product_id ) OR UPDATE (quantity ))

Я надеюсь, последнее хотя бы немного снижает в Ваших глазах необходимость наличия updated?

Признаться, у меня есть маленькая слабость - люблю иногда оставлять ловушки, в частности решил таки не писать про функцию Updating.

Вы никогда не задумывались, как реализован атрибут UPDATE(column), на который Вы сейчас ссылаетесь? Я - для Oracle, само собой, знаю, для MSSQL - поинтересовался. И поэтому позволю задать себе вопрос: Вы действительно не знаете, "как оно работает", или же осознанно попытались подменить ответ на заданный вопрос - "изменено ли значение" - другим и неверным?
20 июл 07, 10:58    [4414277]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
drev
По моему, у нас разное понимание не бизнес-логики, а просто логики.


+1

softwarer уже неоднократно это показал
20 июл 07, 11:13    [4414420]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
drev
1. Даже в приведенных кусках достаточно много смысла.

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


О чём Вы? Какой авторитет у анонима?:)

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


drev
Вы (судя по предыдущим постам) считаете, что проверку нужно делать всегда.

О, сколько интересных утверждений начинаются со слова "очевидно"...

drev
Вы ранее упоминали calculated fields. Вероятно, Вы имели ввиду computed columns. Это решение не всегда подходит.

Не всегда. Тем не менее, сочетание этой фичи с нежеланием запрашивать лишние данные из других таблиц практически не оставляет случаев, когда подобный подсчет в триггере без old будет оптимальным решением. Я не собираюсь утверждать, что "вообще не бывает", но считать достаточно частым случаем, чтобы аргументировать им "объединенную inserted"... не готов.

drev
Возникает вопрос, какой из вариантов в среднем даст лучшую производительность:

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

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



drev
Т.е. решение "сравнивать всегда" - является не совсем корректным.

Угу. Вы вдруг стали математиком и успешно доказали, что математический ноль не равен физическому. Я с этим согласен, но дельта ничуть не приближает нас к утверждению, "да, часто нужен только :new".

Я как бы по образованию математик. Оценка же этого Вашего высказывания совпадает с предыдущим.

drev
Я просто напишу так:
IF ( UPDATE (order_id ) OR UPDATE (product_id ) OR UPDATE (quantity ))

Я надеюсь, последнее хотя бы немного снижает в Ваших глазах необходимость наличия updated?

Признаться, у меня есть маленькая слабость - люблю иногда оставлять ловушки, в частности решил таки не писать про функцию Updating.

Вы никогда не задумывались, как реализован атрибут UPDATE(column), на который Вы сейчас ссылаетесь? Я - для Oracle, само собой, знаю, для MSSQL - поинтересовался. И поэтому позволю задать себе вопрос: Вы действительно не знаете, "как оно работает", или же осознанно попытались подменить ответ на заданный вопрос - "изменено ли значение" - другим и неверным?

Догадываюсь:) Вы серьёзно считаете, что случаи, когда значение в результате осознанной попытки присвоения осталось тем же, составляют более одной тысячной?
20 июл 07, 12:11    [4414888]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
Gluk (Kazan)
drev
По моему, у нас разное понимание не бизнес-логики, а просто логики.


+1

softwarer уже неоднократно это показал


Напомните, кто это там говорил про "full outer join"? :)

И эти люди запрещают нам ковырятся в носу! (с)
20 июл 07, 12:19    [4414951]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

MElin wrote:
> Если уж заморачиваться, то над писать как то так
> select count(*) into l_count from ( select /*+FIRST_ROW */ from tAccount
> where account_id = p_id and rownum = 1 )
пипец :(
а просто
if exists(select * from tAccount where account_id = @pid)
нельзя написать?
ногами не пинать - я читатель оракла, а не писатель.....

зы кстате, корявый код который я приводил - написано 100% ораклоидами :)
причем - юнихоидными - хотя это мало что меняет.

Posted via ActualForum NNTP Server 1.4

20 июл 07, 12:24    [4414994]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
locky

MElin wrote:
> Если уж заморачиваться, то над писать как то так
> select count(*) into l_count from ( select /*+FIRST_ROW */ from tAccount
> where account_id = p_id and rownum = 1 )
пипец :(
а просто
if exists(select * from tAccount where account_id = @pid)
нельзя написать?
ногами не пинать - я читатель оракла, а не писатель.....

зы кстате, корявый код который я приводил - написано 100% ораклоидами :)
причем - юнихоидными - хотя это мало что меняет.


Ты, кстати, зря смеешся Судя по тренду, нам через пару лет смотреть на код, написанный нашими собеседниками:)
20 июл 07, 12:29    [4415041]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
drev
нам через пару лет смотреть на код, написанный нашими собеседниками:)


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

Про full outer в первый раз сказал не я, и сразу же признал свою неправоту
20 июл 07, 12:37    [4415088]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
drev
А вот у людей, писавших код, который Вы отвергли, часть из него не читая, кое-какой авторитет есть. Первый отрывок из Интуит, последний - из примеров к сертификационному экзамену.

Извините, но то что на 11-й странице запостили(если про это идёт речь) - написано безобразно
ну например
Update Table1 set field01 = ...
                  field02 = ...
                  ...
                  fieldn = ...
where god = (select god from inserted) and mes = (select mes from inserted)
во-первых здесь не предусматривается что может быть вставлено несколько записей
во-вторых ну так писать вообще невозможно, любой написал бы
Update е set field01 = ...
                  field02 = ...
                  ...
                  fieldn = ...
from Table1 t , inserted i -- а по-хорошему еще и join бы надо
where t.god =i.god and  t.mes = i.mes
и так можно чуть ли не про любой кусок написать - лень просто
это же не только мне и ChA бросилось в глаза, но и тем для кого Оракл родной
в общем странные у Вас авторитеты

drev
Догадываюсь:) Вы серьёзно считаете, что случаи, когда значение в результате осознанной попытки присвоения осталось тем же, составляют более одной тысячной?

Да полно таких случаев. Очень часто приходится писать вроде:
Update X
set a=a+case A>B then A-B else 0 end,
     b=b+case A>B then 0 else B-A end
Не говоря уже о всяких универсальных гридах, которые обновляют всё "с запасом"

Сообщение было отредактировано: 20 июл 07, 12:43
20 июл 07, 12:41    [4415113]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
Gluk (Kazan)
drev
нам через пару лет смотреть на код, написанный нашими собеседниками:)


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

Про full outer в первый раз сказал не я, и сразу же признал свою неправоту



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

В экономике тренд — направление развития рынка. Тренд также является специфическим понятием в техническом анализе фондовых рынков. Доу даёт следующее определение тренда: «при восходящем (нисходящем) тренде каждый последующий пик и каждый спад должен быть выше (ниже) предыдущего» (см. Теория Доу).


Вы зря обижаетесь. Это было не про Вас. А про Оракл в целом. Какой бы великолепный код Вы не писали, вероятность, что locky доведется на него смотреть существено не нулевая.
20 июл 07, 12:49    [4415181]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
drev
Вы зря обижаетесь. Это было не про Вас. А про Оракл в целом. Какой бы великолепный код Вы не писали, вероятность, что locky доведется на него смотреть существено не нулевая.


Именно об этом я и говорю. Мой код вы вряд ли увидите, возможно вы увидите код softwarer-а, но при этом имеете наглость насмехаться над кодом собеседников хотя те долб[censored] что его написали, вроде бы в беседе не учавствуют (и кстати частично являются вольными или невольными выходцами из лагеря MS SQL).

Когда они кричат разруха, мне СМЕШНО ... надо бить себя по голове (с)
20 июл 07, 12:57    [4415264]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
drev
Тренд — закономерность, характеризующая общую долгосрочную тенденцию в изменениях показателей временного ряда.


Уточните, какую закономерность Вы имели в виду в ВАШЕМ высказывании ???
20 июл 07, 13:06    [4415341]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 [13] 14 15 16 17 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить