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

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

locky
Ага. "псевдо юзер"......
Стрелять за такое.

Не нравится юзер: есть ещё роли и контекстные переменные.

Контекстные переменные - это уже куда лучше. Значительнее.
А юзера - нафиг-нафиг.
Поведение триггера должно зависить от того что хотят сделать, а не от того, кто это делает.
10 дек 09, 21:06    [8049271]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Dimitry Sibiryakov

Если в Language Reference Вы нащли только ALTER TRIGGER INACTIVE, а до
CURRENT_USER, который обычно и используют для обхода триггерной логики
не докопались, то тут уже поможет только хирургия.

Может, я и идиот, но моя цель звучит не как "использовать триггеры", а
делать качественные системы, но поскольку ваш подход единственно верный,
то пойду и убьюсь апстену.
С уважением.
10 дек 09, 21:54    [8049462]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
ОКТОГЕН
1)Отключение триггеров в транзакции блокирует таблицу целиком.
Если вместо есть транзакция, в которой вместо триггера должен выполнятся другой код,
то головная боль обеспечена.

А вот интересно, отключить индекс, pk или fk в postgre тоже вызывает такие проблемы? Если да, то они как минимум зло на две трети, согласно этому высказыванию.
10 дек 09, 22:17    [8049558]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
ОКТОГЕН

Может, я и идиот, но моя цель звучит не как "использовать триггеры",
С уважением.

Пардон, были озвучены три причины неиспользования триггеров. 1-ю и 3-ю проблему решили. Значит причин неиспользовать триггеры нет, фактически.
10 дек 09, 22:26    [8049579]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
FreemanZAV
Member

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

А причина страха очевидна. До этого они столкнулись с реализацией оных в MSSQL

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

Забавно, что речь о курсорах не шла.
10 дек 09, 22:27    [8049584]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
locky
курсоры куда ни попадя (зачастую от ненадлежащего знания матчасти) - есть зло.

поддерживаю. в отличие от "триггеры - зло".

pkarklin
Поляковой Ларисе Николаевне самой бы курсы послушать...

могобыть. я полез туда за просмотром синтаксиса. синтаксис поначалу опасений не вызывает. Сильно смутили inserted/deleted, о которых я и раньше знал. в FB, например, любые триггеры только FOR EACH ROW, если использовать терминологию Оракла. И before/after без проблем. И в FB триггеры используются не только для обработки, но и как "замена" сложных check constraint, причем использование их как before не требует никаких "откатов транзакций" и т.п. Я ж говорю, что архитектуры разные.
Зачем, опираясь на архитектуру триггеров и транзакций в MS SQL, проводить параллели "зла" на все остальные СУБД?

потом, я нашел например
https://www.sql.ru/articles/mssql/02021201AuditingThroughTriggers.shtml
автор - Сатана?

В ФБ например есть Execute Statement, т.е. выполнение SQL из переменных в коде процедур и триггеров. Да, можно сказать что это зло, потому что новички, и особенно приходящие с других серверов, начинают использовать эту фичу напропалую, вместо продумывания кода и написания нормальных процедур и запросов.
Так что, в MS SQL одно зло, а в других СУБД - другое зло. Опять же, в MS SQL нет триггеров на view. Это "добро"? А в FB они есть. :-)
10 дек 09, 22:28    [8049585]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
Dimitry Sibiryakov
Member

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

kdv
Опять же, в MS SQL нет триггеров на view.

Вообще-то - есть.

Posted via ActualForum NNTP Server 1.4

10 дек 09, 22:37    [8049605]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
locky
Member

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

А причина страха очевидна. До этого они столкнулись с реализацией оных в MSSQL

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

Забавно, что речь о курсорах не шла.

Забавно, что вы не в курсе о проблемах в применении курсоров
10 дек 09, 22:44    [8049635]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
ВЫ
Вообще-то - есть.

блин. только что смотрел в
http://msdn.microsoft.com/ru-ru/library/ms189799.aspx
была такая фраза. теперь смотрю - не вижу.

а. есть ограничения. FOR | AFTER
"Триггеры AFTER не могут быть определены на представлениях." с другой стороны, тут же взаимоисключающая фраза:
"Если единственным заданным ключевым словом является FOR, аргумент AFTER используется по умолчанию."
И правда зло...
10 дек 09, 22:45    [8049638]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
Dimitry Sibiryakov
Member

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

kdv
была такая фраза. теперь смотрю - не вижу.

Плюнь, дока у МС тоже не блистает. Смотри в синтаксическую диаграмму:
CREATE TRIGGER trigger_name
ON { table | view }

Posted via ActualForum NNTP Server 1.4

10 дек 09, 22:51    [8049666]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
FreemanZAV
Member

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

Забавно, что вы не в курсе о проблемах в применении курсоров

Почему это. Как раз я теперь знаю, что проблем с примененим курсоров в оракле нет, ибо
locky
они там неплохо реализованы

Теперь остаётся узнать, какая связь между триггерами и курсорами
10 дек 09, 22:52    [8049672]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
locky
Member

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

Забавно, что вы не в курсе о проблемах в применении курсоров

Почему это. Как раз я теперь знаю, что проблем с примененим курсоров в оракле нет, ибо
locky
они там неплохо реализованы

Теперь остаётся узнать, какая связь между триггерами и курсорами

Вот ведь прости господи
Да, проблем с реализацией курсоров в оракле нет.
Есть проблема с применением.
10 дек 09, 22:57    [8049695]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
FreemanZAV
Member

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

Да, проблем с реализацией курсоров в оракле нет.
Есть проблема с применением.

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

Ну так а триггеры здесь при чём?
10 дек 09, 23:00    [8049708]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
locky
Member

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

Да, проблем с реализацией курсоров в оракле нет.
Есть проблема с применением.

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

стейтмент drop там тоже хорошо реализован, но это совершенно не значит что его нужно постоянно применять.

FreemanZAV

Ну так а триггеры здесь при чём?

см. выше. Применимость фичи обосновывается не качеством её реализации.
Ты будешь применять плохо реализованную фичу, если таки она тебе реально нужна.
И аналогично - не следует применять ненужную (в данном случае) фичу только потому что она "хорошо реализована".
10 дек 09, 23:06    [8049739]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4809
locky
Применимость фичи обосновывается не качеством её реализации.
Ты будешь применять плохо реализованную фичу, если таки она тебе реально нужна.
И аналогично - не следует применять ненужную (в данном случае) фичу только потому что она "хорошо реализована".
+1.
очевиднейшая, вроде, вещь сказана, но, почему-то она непонятой оппонентами остаётся.
10 дек 09, 23:10    [8049755]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
FreemanZAV
Member

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

Но и "злом" его не назовёшь

locky
И аналогично - не следует применять ненужную (в данном случае) фичу только потому что она "хорошо реализована".

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

Если с этих позиций рассуждать, то да, триггера - зло, впрочем, как и самовары.
10 дек 09, 23:17    [8049787]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
Энди Таккер
Member

Откуда:
Сообщений: 363
egorych
очевиднейшая, вроде, вещь сказана, но, почему-то она непонятой оппонентами остаётся.

Очевиднейшая вещь звучала так:
locky
триггера - зло. Иногда - необходимое, но зло - однозначно.

и
locky
я "сталкиваюсь" с реализацией курсоров в оракле (а они там неплохо реализованы).
Но по прежнему считаю что чем совать курсоры куда ни попадя (зачастую от ненадлежащего знания матчасти) - есть зло.


Между фразами "зло - однозначно" и "совать куда ни попадя - есть зло" просматривается "очевиднейшая" разница. Вот оппоненты и хотят разрешить данную логическую нестыковку.
11 дек 09, 05:58    [8050198]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
locky
Member

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

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

Оппонентам просто хочется пофлудить и несколько оправдать себя
Всегда нелегко, когда кто-то приходит и говорит что твой стиль работы - полная фигня. Это очень обидно. Ведь мы так ловко выпутываемся из ситуаций, в которые же сами и попали!
11 дек 09, 08:45    [8050399]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
Никак не могу получить ответ на один вопрос. В MSSQL можно при ошибке в процедуре посмотреть стек?
11 дек 09, 09:21    [8050525]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 5019
ОКТОГЕН
Если вместо есть транзакция, в которой вместо триггера должен выполнятся другой код, то головная боль обеспечена.

Это следствие неправильно спроектированной структуры. С какой стати в какой-то там транзакции что-то должно выполняться вместо триггера? Зачем вам в данном случае триггер?
В триггере надо выполнять те действия, которые ВСЕГДА выполняются при изменении данных. Имхо...
За редким исключением, на этот случай есть отключение триггера, но на то это и редкое исключение, что возникает не так часто, чтобы быть проблемой.
---
Проходя мимо разложенных граблей, ты теряешь драгоценный опыт. (с)
11 дек 09, 10:25    [8050866]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
FreemanZAV
Никак не могу получить ответ на один вопрос. В MSSQL можно при ошибке в процедуре посмотреть стек?


Нет.

In the scope of a CATCH block, the following system functions can be used to obtain information about the error that caused the CATCH block to be executed:

  • ERROR_NUMBER() returns the number of the error.
  • ERROR_SEVERITY() returns the severity.
  • ERROR_STATE() returns the error state number.
  • ERROR_PROCEDURE() returns the name of the stored procedure or trigger where the error occurred.
  • ERROR_LINE() returns the line number inside the routine that caused the error.
  • ERROR_MESSAGE() returns the complete text of the error message. The text includes the values supplied for any substitutable parameters, such as lengths, object names, or times.
  • 11 дек 09, 10:28    [8050890]     Ответить | Цитировать Сообщить модератору
     Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
    FreemanZAV
    Member

    Откуда:
    Сообщений: 2434
    А стек-то где?
    11 дек 09, 10:41    [8051011]     Ответить | Цитировать Сообщить модератору
     Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
    pkarklin
    Member

    Откуда: Москва (Муром)
    Сообщений: 74930
    FreemanZAV,

    pkarklin
    Нет.


    Вы это пропустили?
    11 дек 09, 10:46    [8051066]     Ответить | Цитировать Сообщить модератору
     Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
    FreemanZAV
    Member

    Откуда:
    Сообщений: 2434
    pkarklin
    FreemanZAV,

    pkarklin
    Нет.


    Вы это пропустили?

    Пардон, пропустил.
    11 дек 09, 10:56    [8051202]     Ответить | Цитировать Сообщить модератору
     Re: MS SQL Express vs PostgreSQL/SQLite/FireBird  [new]
    andy st
    Member

    Откуда:
    Сообщений: 899
    FreemanZAV
    Никак не могу получить ответ на один вопрос. В MSSQL можно при ошибке в процедуре посмотреть стек?

    Стек вызовов процедур можно увидеть, используя SQL Profiler + отлов SP:StmtStarting и SP:StmtCompleted.
    11 дек 09, 11:01    [8051259]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 8 9 10 [11] 12   вперед  Ctrl      все
    Все форумы / Сравнение СУБД Ответить