Работа уникальными значениями

← →
Delirium © (2004-05-24 16:43) [40]

"Что же я там должен увидеть.Это же подмена вставки, а не полноценный триггер BEFORE INSERT" - правильно, это более мощная конструкция, нежели "BEFORE INSERT", иначе говоря "BEFORE INSERT" - частный случай "INSTEAD OF INSERT". Думаю, вопрос решён.

P.S. "в MSSQL нет некоторых основопологающих вещей" - это ваше частное и в общем случе безграмотное мнение. Прежде чем так высказываться, дайте определение "основопологающих вещей" не забыв добавить IMHO.

← →
ega23 © (2004-05-24 16:51) [41]

в MSSQL нет некоторых основопологающих вещей.
А что есть "основопологающая вещь"?

← →
den_777 (2004-05-24 17:08) [42]

> Думаю, вопрос решён.

Ну объясни мне тогда безграмотному как реализовать в MSSQL аналог

IF NEW.ID IS NULL THEN NEW.ID=54677
Причем поле ID NOT NULL.

P.S. Не гоже умному человеку судить о грамотности или безграмотности другого человека только по одному посту, пусть даже и идущему наперекор с твоими убеждениями. А насчет IMHO, так все что я здесь высказал и так есть IMHO, а не истина в последней инстанции, зачем каждый раз добавлять то, что и так само собой разумеется.

← →
Sandman25+1 (2004-05-24 17:11) [43]

IF NEW.ID = 0 THEN NEW.ID=54677

← →
ega23 © (2004-05-24 17:18) [44]

IF NEW.ID IS NULL THEN NEW.ID=54677

ДА ЗАЧЕМ ТЕБЕ ТАКАЯ КОНСТРУКЦИЯ?!?!?!?!?!?
И как первичный ключ, на твой взгляд, может быть NULL?

← →
Delirium © (2004-05-24 17:19) [45]

"IF NEW.ID IS NULL THEN NEW.ID=54677
Причем поле ID NOT NULL." - MSSQL строгая СУБД и даже с INSTEAD OF не допустит такого варварства, как попытка отправить null в поле not null. И это есть хорошо.

← →
Delirium © (2004-05-24 17:23) [46]

Вообще говоря INSTEAD OF триггера сделаны в основном для представлений, а не для таблиц я привёл эту конструкцию в опровержение тезиса о BEFORE триггерах. Собственно сама постановка задачи говорит об изъянах при проектировании БД.

← →
ega23 © (2004-05-24 17:27) [47]

Собственно сама постановка задачи говорит об изъянах при проектировании БД.

Золотые слова!

← →
den_777 (2004-05-24 17:47) [48]

Т.е. у всех кто по неосторожности прочитал статью "безграмотного" Дмитрия Кузьменко http://www.ibase.ru/devinfo/generator.htm
или даже не читая данной статьи тысячи программистов пользуясь данной конструкцией оказывается неправильно проектировали базы данных.Наверное сказать

> Собственно сама постановка задачи говорит об изъянах при
> проектировании БД.

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

Delirium сначала говорим

> "BEFORE INSERT" - частный случай "INSTEAD OF INSERT".

потом оправдываемся

> Вообще говоря INSTEAD OF триггера сделаны в основном для
> представлений

Ну так как же все-таки на самом деле.

← →
Romkin © (2004-05-24 17:54) [49]

ega23 © (24.05.04 17:18) [44] В IB все проверки констреинтов идут после триггера before, посему такая конструкция вполне естественна :)
Delirium © (24.05.04 17:19) [45] угу. Вот именно, поскольку нету триггера before, а он и предназначен для заполнения полей, и все (!) проверки целостности идут после него. В том числе и на not NULL... IB тоже "не допустит такого варварства, как попытка отправить null в поле not null". Только дело в том, что в момент нахождения в триггере before insert никто еще ничего в таблицу не пихнул ;)

← →
ega23 © (2004-05-24 18:14) [50]

ega23 © (24.05.04 17:18) [44] В IB все проверки констреинтов идут после триггера before, посему такая конструкция вполне естественна :)

Может быть, спорить не буду. Тем более, что не знаком с IB. Я не могу понять, зачем она вообще такая нужна?

← →
Delirium © (2004-05-24 18:19) [51]

"Только дело в том, что в момент нахождения в триггере before insert никто еще ничего в таблицу не пихнул" - так-то оно так, да только вот это уже не тот уровень целостности, т.е. если некто ошибся в написании триггера в поле попадёт таки null-овое значение, СУБД вызовет исключение, что повлечёт разрушение транзакции. MSSQL-же, следуя политике не доверять пользовательским триггерам, посто не даст такой ситуации возникнуть! Он будет разрушать любую транзакцию с null. В данном случае ограниечение - не слабость СУБД (думаю, никто не сомневается в технической ничтожности задачи - опустить проверку на null с INSTEAD OF уровня, до уровня записи и обычных триггеров), ребята из Microsoft просто большие теоретики и академичнось подхода у них в идеалогии. Что опять таки - есть хорошо.

← →
Delirium © (2004-05-24 18:24) [52]

Скажу более, этим своим шагом Microsoft одним махом отсёк целый пласт возможных ошибок в триггерах, задумайтесь над красотой решения, если я не хочу чтобы в конкретном поле были null, я могу быть уверен, что и в триггерах их не будет! Как сей уровень безопасности обеспечить в before от IB ?

← →
den_777 (2004-05-24 18:34) [53]

чем отличается

> СУБД вызовет исключение, что повлечёт разрушение транзакции.

от

> Он будет разрушать любую транзакцию с null.

в любом случае NULL в таблицу записан не будет, и транзакция откатится. Только в первом случае у разработчика БД есть шанс исправить некорректное значение на лету на то, которое по его мнению можно подставить вместо NULL, т.е. тот же самый DEFAULT только с большими возможностями. Так что уровень безопасноти целостности данных в IB на должном уровне, и запись некорретных значений(не удовлетворяющих каким-либо constraints) в БД он тоже не допустит. О порядке проверки целостности читай

> Romkin © (24.05.04 17:54) [49]

← →
ega23 © (2004-05-24 18:47) [54]

Триггер, ИМХО, вообще вредная вещь. Только один раз использовал, но тогда без него действительно было не обойтись. А в остальном ХП его заменяет здорово.

← →
Delirium © (2004-05-24 18:52) [55]

Глупо спроить о преимуществах и недостатках двух серьёзных СУБД основываясь лишь на эмоциях. Я считаю (и Microsoft со мной согласен), что триггер - неотъемлемая часть таблицы и на него распространяются те-же правила, что и на таблицу. Вы считаете, что триггер это, грубо говаря, хранимая процедура живущая сама по себе и вызываемая при записи. И то и другое мнение имеет право на существование. Собственно к subj-у это уже не имеет отношения. Однако, раз по результатам опроса sql.ru (http://www.sql.ru/poll/) MSSQL лидирует с хорошим отрывом - видимо, объективно, он чем-то лучше других :)

видимо, объективно, он чем-то лучше других :)
Был бы хуже - писал бы на IB :о)

← →
den_777 (2004-05-24 19:37) [57]

> MSSQL лидирует с хорошим отрывом - видимо, объективно, он
> чем-то лучше других :)

Этот опрос вообще не говорит о том что какая-то СУБД лучше или хуже другой, а то так и до вывода что Visual FoxPro лучше DB2 и INFORMIX вместе взятых недалеко. Этот опрос только и свидетельствует о том кто с какой базой работает(в соответствии с постановкой самого вопроса при опросе респондентов) и ни о чем более.

"вывода что Visual FoxPro лучше DB2 и INFORMIX вместе взятых недалеко" - а почему бы и нет, если существенная доля задач не требут мощи DB2 и удобства INFORMIX, а программисты VFP ещё и стоят дешевле, то - разумеется VFP даёт всем фору! :)

P.S. Это рынок - тут демагогии места нет ;)

> den_777 (24.05.04 16:15) [38]
> Два пользователя вставляют данные в одну и туже таблицу, но у обоих пользователей большие транзакции с вставкой данных в несколько таблиц. Первая транзакция получает значение 6, вторая 7...
>Может я что-то не так понимаю, объясните пожалуйста.

Т.к. MS SQL блокировочник, то пока не закончится транзакция 1 пользователя, вторая не сможет стартовать

← →
Sandman25+1 (2004-05-26 09:05) [60]

[59] ЮЮ © (26.05.04 03:08)

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

Работа уникальными значениями Найти похожие ветки