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

Повторяю
update ...... current of
22 май 09, 12:42    [7214980]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Полугурок
Member [заблокирован]

Откуда: из гурдома
Сообщений: 56
Кудряшка
пусть вон тот ораклоид Полугурок, который тут словами "ламерские" разбрасывается, отвечает, если сам не ламер!
могу только сказать харьковским долбоёбам, "тихо сам с собою ведущим беседу", что не хрен давать свои тупые оценки и советы в тех областях, где ни хера не смыслишь. Тогда и ламером называть не будут
Модератор: забанен за этот пост


Сообщение было отредактировано: 22 май 09, 15:17
22 май 09, 14:20    [7215795]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
SQLap
Member [заблокирован]

Откуда:
Сообщений: 34063
Еще один пример использования ROWID - ALTER TABLE ENABLE CONSTRAINT EXCEPTIONS INTO...
22 май 09, 14:29    [7215868]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Эталон Этанолович
Member

Откуда: Институт благородных девиц. Палата №6
Сообщений: 332
Полугурок
Модератор: забанен за этот пост
Ага, спасибо на добром слове. Может харьковскому ламеру легче станет :)
22 май 09, 16:28    [7216825]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Пилот Пиркс
Member

Откуда: Москва
Сообщений: 352
Кудряшка
Полугурок
Это широко растопыренные ламерские пальцы ;-)


примеры практического использования в разработке в реальной жизни на реальных задачах, плз, продемонстрируйте :)


Вот например то, что я применяю в реальной жизни :)
1 - Поиск строки, с последующей её обработкой.
 select ... , rowid into ... v_rowid  from ...;
 .... обработка ..
 update ... where  rowid = v_rowid ;

2 - Логирование информации о том, "на какой строке всё сломалось" если в таблице-источнике нет уникального ключа.

3 - Удаление дубликатов.
22 май 09, 16:29    [7216830]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Применений намного больше, Пилот Пиркс назвал. Например, администраторы часто применяют при разборе полетов (сделать дамп блока с этой строкой, сделать дамп блока индекса для данной строки) или с помощью DBMS_SQL.LAST_ROW_ID можно узнать какая строка была обработана последней. И много чего еще. Просто тетенька похоже плохо понимаем о чем говорит, а некоторых такое баранье упрямство немнго бесит.
23 май 09, 14:47    [7218724]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Кудряшка
Member

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

2 - Логирование информации о том, "на какой строке всё сломалось" если в таблице-источнике нет уникального ключа.

3 - Удаление дубликатов.


1. Если нет на таблице уникального ключа - это ошибка проектирования. И это допустимо только на стадии разработки/тестирования, но никак не в живых базах.
2. Если записи дублируются полностью - нет никакой разницы, какую из них удалять.
3. Если записи дублируются не полностью, т.е. видно, что дубликат (по неким полям, которые как ы предполагаются быть уникальными, например e-mail в таблице Users. Т.е. e-mail одинаковый, а ФИО разное), ROWID ничего не даст. В никак не определите, какую из записей удалять.

Т.е. оба примера - по сути заплатки...
24 май 09, 03:35    [7219522]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
_мод
Повторяю
update ...... current of


а можете суть процесса описать?
24 май 09, 03:36    [7219523]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
Gluk (Kazan)
Просто примите как данность - без ROWID индексов бы в Oracle не було. Не думаю, что это сильно помогло бы прикладникам. По мне так странно называть бесполезным механизм, на котором базируется то без чего никак не обойтись в реальной жизни. Ну а то что в суе их лучше не трепать, тем которые на Oracle что то разрабатывают, так это факт (никто в здравом уме вроде как и не утверждал обратного).


Согласна полностью.
Мой вопрос был, конечно же, о примемении в разработке прилажений на Oracle. И в необходимости доступности ROWID разработчикам.
24 май 09, 03:48    [7219527]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Кудряшка
2. Если записи дублируются полностью - нет никакой разницы, какую из них удалять.

Согласен. Поэтому давайте удалим вот эту. А как же написать delete, если под условие попадают все такие записи? Значит, надо как-то уникально идентифицировать одну из них, дабы исключить её из условия.
24 май 09, 16:14    [7220047]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Пилот Пиркс
Member

Откуда: Москва
Сообщений: 352
Кудряшка
Пилот Пиркс

2 - Логирование информации о том, "на какой строке всё сломалось" если в таблице-источнике нет уникального ключа.

3 - Удаление дубликатов.

......
Т.е. оба примера - по сути заплатки...


Пункт 3 не заплатка, а применяется тогда, когда какая-то группа полей была не уникальна, а мы хотим сделать её уникальной. Перед этим надо удалить( или как-то ещё обработать) дубликаты. Как это сделать одним запросом без rowid я не знаю, уж извините :) Так что тут он мне нужен.

По поводу "Если нет на таблице уникального ключа - это ошибка проектирования" не могу согласиться. Вот, например, логи вёб сервера. Какой уникальный ключ для строки выбрать? Или логи роутера. Каждая запись в логе не имеет уникального идентификатора. Я могу продолжать. Суть в том, что такое бывает и с этим надо как-то работать. Отмахуться "это всё заплатки" не получится :)
24 май 09, 22:06    [7220489]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
AAron
Member

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

интересно, как же на других серверах удаляют дубликаты без использования rowid? а ведь должны как-то

по поводу логов, уж если не можете выбрать ключ, так незачем всем об этом рассказывать. между прочим, логи лучше пропускать сначала через ETL, а то смысла в них...
24 май 09, 22:21    [7220501]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
AAron
Пилот Пиркс,

интересно, как же на других серверах удаляют дубликаты без использования rowid? а ведь должны как-то

по поводу логов, уж если не можете выбрать ключ, так незачем всем об этом рассказывать. между прочим, логи лучше пропускать сначала через ETL, а то смысла в них...
В Firebird есть RDB$DB_KEY, но сомневаюсь по поводу последовательности его значений.
24 май 09, 22:39    [7220526]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67377
Блог
locky
А как же написать delete, если под условие попадают все такие записи? Значит, надо как-то уникально идентифицировать одну из них, дабы исключить её из условия.

Ну, сугубо истины ради - в Oracle можно удалить "не все полные дубли" без использования ROWID :)
24 май 09, 22:48    [7220540]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
locky
Member

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

Ну, сугубо истины ради - в Oracle можно удалить "не все полные дубли" без использования ROWID :)

В мс-скл тоже, но это совершенно не значит, что это завсегда удобно :)
как я говорил раньше, rowid очень удобен с технологической точки зрения. Можно и без него, но с ним тупо удобнее :)
25 май 09, 00:18    [7220673]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
locky
как я говорил раньше, rowid очень удобен с технологической точки зрения. Можно и без него, но с ним тупо удобнее :)


Лично у меня возражений нет :)
25 май 09, 04:01    [7220811]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
Кудряшка
locky
как я говорил раньше, rowid очень удобен с технологической точки зрения. Можно и без него, но с ним тупо удобнее :)


Лично у меня возражений нет :)


Т.е. можно присесть 1 раз, а можно 5 - но задача решаема в любом случае.
25 май 09, 04:02    [7220812]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Кудряшка
Мой вопрос был, конечно же, о примемении в разработке прилажений на Oracle. И в необходимости доступности ROWID разработчикам.


Дык оно админам было сделано доступным :)
Разработчиков за такое надо изымать из генофонда
25 май 09, 08:13    [7220926]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
AAron
Пилот Пиркс,

интересно, как же на других серверах удаляют дубликаты без использования rowid? а ведь должны как-то

Как вариант:
create table t2 as select f1,f2,f3 from t1 group by f1,f2,f3

AAron

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

Не надо все пытаться натягивать тему OLAP\DWH.
25 май 09, 09:36    [7221149]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Gluk (Kazan)
Кудряшка
Мой вопрос был, конечно же, о примемении в разработке прилажений на Oracle. И в необходимости доступности ROWID разработчикам.


Дык оно админам было сделано доступным :)
Разработчиков за такое надо изымать из генофонда

Ну, вот не надо так категорично... Есть ряд случаев, когда это действительно полезно в т.ч. и разработчику. Например, при интенсивной обработке строк через коллекции бывает выгоднее сбрасывать изменения в таблицу не по первичному ключу, а по rowid - LIO уменьшается в разы. Иногда это критично. Разумеется, необходимо быть уверенным, что ROWID не изменится в процессе обработки, но это уже дело техники.
25 май 09, 09:46    [7221183]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Эталон Этанолович
Member

Откуда: Институт благородных девиц. Палата №6
Сообщений: 332
Кудряшка
1. Если нет на таблице уникального ключа - это ошибка проектирования. И это допустимо только на стадии разработки/тестирования, но никак не в живых базах.
2. Если записи дублируются полностью - нет никакой разницы, какую из них удалять.
3. Если записи дублируются не полностью, т.е. видно, что дубликат (по неким полям, которые как ы предполагаются быть уникальными, например e-mail в таблице Users. Т.е. e-mail одинаковый, а ФИО разное), ROWID ничего не даст. В никак не определите, какую из записей удалять.

1 и 2 - чушь, 3 - наполовину чушь.

P.S. Не надоело нести пургу?
25 май 09, 11:51    [7221951]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Пилот Пиркс
Member

Откуда: Москва
Сообщений: 352
AAron
интересно, как же на других серверах удаляют дубликаты без использования rowid? а ведь должны как-то

Ну раз должны и могут - молодцы :) Я в оракле это делаю это одним запросом с использованием rowid. Для этого он мне и нужен. О чём тут ещё можно говорить? Мы ведь спорим о том, что rowid нужен/удобен/полезен или нет.

AAron
по поводу логов, уж если не можете выбрать ключ, так незачем всем об этом рассказывать. между прочим, логи лучше пропускать сначала через ETL, а то смысла в них...

Выберете мне ключ для записей в логе вёб сервера, плиз :) Как раз для использования в ETL, без которого, по Вашему мнению смысла в логах нет.
25 май 09, 11:51    [7221956]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
Эталон Этанолович

1 и 2 - чушь, 3 - наполовину чушь.

P.S. Не надоело нести пургу?


Есть нормальные аргументы?

П.С.: Ваше высокопарное "чушь" и "пурга" - лично для меня не аргумент.
25 май 09, 12:07    [7222064]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
Solmyr
Member

Откуда: город К. -> город М.
Сообщений: 538
Кудряшка
(а нечего было на наши временные таблицы наезжать :-P )

Gluk (Kazan)
А где я наезжал на ваши временные таблицы ?


Эт я наежжал. :) И чем же вас так впечатляют втмс?
25 май 09, 12:11    [7222094]     Ответить | Цитировать Сообщить модератору
 Re: PL/SQL vs.Transact SQL  [new]
дддддд
Guest
Кудряшка
Эталон Этанолович

1 и 2 - чушь, 3 - наполовину чушь.

P.S. Не надоело нести пургу?


Есть нормальные аргументы?

П.С.: Ваше высокопарное "чушь" и "пурга" - лично для меня не аргумент.


Есть 2 одинаковые записи, но на одну из них есть ссылки из дочерних таблиц. Продолжить?
25 май 09, 12:18    [7222138]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 12 [13] 14 15 16   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить