| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Работа уникальными значениями [D7, IB6.x, MSSQL]
den_777 © (2004-05-24 09:46:00)Пока мне приходилось работать только с INFORMIX и IB,FB. Поэтому приведу пример на этих базах.
Надо чтобы была возможность автоматической и ручной вставки значения в поле которое является PRIMARY KEY, т.е. для таблицы с полями ID и CNAME проходили оба SQL insert into tbl1(id,cname) values(0,"myname") и insert into tbl1(cname) values("myname")
Соответственно в INFORMIX я просто задаю этому полю тип SERIAL и все, больше ничего делать не надо. В первом случае INFORMIX просто проверяет не противоречит ли вставляемое мной значение уникальности и если нет то вставляет его во втором случае сам генерит следующее значение.
В IB,FB это решается с помощью генератора и триггера IF NEW.ID IS NULL THEN NEW.ID=GEN_ID(MY_GEN,1).
Вопрос как таких же действий добиться от MSSQL. И вопрос в догонку, если в других базах какой-либо функционал был заложен в триггер перед вставкой, то как этот же функционал реализовать в MSSQL.
asp (2004-05-28 11:34:00) [1]Delirium © (25.05.04 16:07) [58] >
Рынок говорит, что объем продаж DB2 существенно опережает MSSQL.
Sandman25+1 (2004-05-26 09:05:00) [2][59] ЮЮ © (26.05.04 03:08)
Informix тоже блокировочник, но тем не менее при вставке в таблицу с автоинкрементным полем никаких взаимных блокировок не будет. Блокируется только вставленная запись, до которой никому пока нет дела.
ЮЮ (2004-05-26 03:08:00) [3]> den_777 (24.05.04 16:15) [38]
> Два пользователя вставляют данные в одну и туже таблицу, но у обоих пользователей большие транзакции с вставкой данных в несколько таблиц. Первая транзакция получает значение 6, вторая 7...
>Может я что-то не так понимаю, объясните пожалуйста.
Т.к. MS SQL блокировочник, то пока не закончится транзакция 1 пользователя, вторая не сможет стартовать
Delirium (2004-05-25 16:07:00) [4]"вывода что Visual FoxPro лучше DB2 и INFORMIX вместе взятых недалеко" - а почему бы и нет, если существенная доля задач не требут мощи DB2 и удобства INFORMIX, а программисты VFP ещё и стоят дешевле, то - разумеется VFP даёт всем фору! :)
P.S. Это рынок - тут демагогии места нет ;)
den_777 (2004-05-24 19:37:00) [5]
> MSSQL лидирует с хорошим отрывом - видимо, объективно, он
> чем-то лучше других :)
Этот опрос вообще не говорит о том что какая-то СУБД лучше или хуже другой, а то так и до вывода что Visual FoxPro лучше DB2 и INFORMIX вместе взятых недалеко. Этот опрос только и свидетельствует о том кто с какой базой работает(в соответствии с постановкой самого вопроса при опросе респондентов) и ни о чем более.
ega23 (2004-05-24 19:07:00) [6]видимо, объективно, он чем-то лучше других :)
Был бы хуже - писал бы на IB :о)
Delirium (2004-05-24 18:52:00) [7]Глупо спроить о преимуществах и недостатках двух серьёзных СУБД основываясь лишь на эмоциях. Я считаю (и Microsoft со мной согласен), что триггер - неотъемлемая часть таблицы и на него распространяются те-же правила, что и на таблицу. Вы считаете, что триггер это, грубо говаря, хранимая процедура живущая сама по себе и вызываемая при записи. И то и другое мнение имеет право на существование. Собственно к subj-у это уже не имеет отношения. Однако, раз по результатам опроса sql.ru ( http://www.sql.ru/poll/) MSSQL лидирует с хорошим отрывом - видимо, объективно, он чем-то лучше других :)
ega23 (2004-05-24 18:47:00) [8]Триггер, ИМХО, вообще вредная вещь. Только один раз использовал, но тогда без него действительно было не обойтись. А в остальном ХП его заменяет здорово.
den_777 (2004-05-24 18:34:00) [9]чем отличается
> СУБД вызовет исключение, что повлечёт разрушение транзакции.
от
> Он будет разрушать любую транзакцию с null.
в любом случае NULL в таблицу записан не будет, и транзакция откатится. Только в первом случае у разработчика БД есть шанс исправить некорректное значение на лету на то, которое по его мнению можно подставить вместо NULL, т.е. тот же самый DEFAULT только с большими возможностями. Так что уровень безопасноти целостности данных в IB на должном уровне, и запись некорретных значений(не удовлетворяющих каким-либо constraints) в БД он тоже не допустит. О порядке проверки целостности читай
> Romkin © (24.05.04 17:54) [49]
Delirium (2004-05-24 18:24:00) [10]Скажу более, этим своим шагом Microsoft одним махом отсёк целый пласт возможных ошибок в триггерах, задумайтесь над красотой решения, если я не хочу чтобы в конкретном поле были null, я могу быть уверен, что и в триггерах их не будет! Как сей уровень безопасности обеспечить в before от IB ?
Delirium (2004-05-24 18:19:00) [11]"Только дело в том, что в момент нахождения в триггере before insert никто еще ничего в таблицу не пихнул" - так-то оно так, да только вот это уже не тот уровень целостности, т.е. если некто ошибся в написании триггера в поле попадёт таки null-овое значение, СУБД вызовет исключение, что повлечёт разрушение транзакции. MSSQL-же, следуя политике не доверять пользовательским триггерам, посто не даст такой ситуации возникнуть! Он будет разрушать любую транзакцию с null. В данном случае ограниечение - не слабость СУБД (думаю, никто не сомневается в технической ничтожности задачи - опустить проверку на null с INSTEAD OF уровня, до уровня записи и обычных триггеров), ребята из Microsoft просто большие теоретики и академичнось подхода у них в идеалогии. Что опять таки - есть хорошо.
ega23 (2004-05-24 18:14:00) [12]ega23 © (24.05.04 17:18) [44] В IB все проверки констреинтов идут после триггера before, посему такая конструкция вполне естественна :)
Может быть, спорить не буду. Тем более, что не знаком с IB. Я не могу понять, зачем она вообще такая нужна?
Romkin (2004-05-24 17:54:00) [13]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 никто еще ничего в таблицу не пихнул ;)
den_777 (2004-05-24 17:47:00) [14]Т.е. у всех кто по неосторожности прочитал статью "безграмотного" Дмитрия Кузьменко http://www.ibase.ru/devinfo/generator.htm
или даже не читая данной статьи тысячи программистов пользуясь данной конструкцией оказывается неправильно проектировали базы данных.Наверное сказать
> Собственно сама постановка задачи говорит об изъянах при
> проектировании БД.
намного легче, чем понять суть вопроса.
Мне просто интересно, Delirium ты хотя бы выдвигая это тезис, прочитал всю ветку, или по два поста в начале и в конце.
Delirium сначала говорим
> "BEFORE INSERT" - частный случай "INSTEAD OF INSERT".
потом оправдываемся
> Вообще говоря INSTEAD OF триггера сделаны в основном для
> представлений
Ну так как же все-таки на самом деле.
ega23 (2004-05-24 17:27:00) [15]Собственно сама постановка задачи говорит об изъянах при проектировании БД.
Золотые слова!
Delirium (2004-05-24 17:23:00) [16]Вообще говоря INSTEAD OF триггера сделаны в основном для представлений, а не для таблиц я привёл эту конструкцию в опровержение тезиса о BEFORE триггерах. Собственно сама постановка задачи говорит об изъянах при проектировании БД.
Delirium (2004-05-24 17:19:00) [17]"IF NEW.ID IS NULL THEN NEW.ID=54677
Причем поле ID NOT NULL." - MSSQL строгая СУБД и даже с INSTEAD OF не допустит такого варварства, как попытка отправить null в поле not null. И это есть хорошо.
ega23 (2004-05-24 17:18:00) [18]IF NEW.ID IS NULL THEN NEW.ID=54677
ДА ЗАЧЕМ ТЕБЕ ТАКАЯ КОНСТРУКЦИЯ?!?!?!?!?!?
И как первичный ключ, на твой взгляд, может быть NULL?
Sandman25+1 (2004-05-24 17:11:00) [19]IF NEW.ID = 0THEN NEW.ID=54677
den_777 (2004-05-24 17:08:00) [20]
> Думаю, вопрос решён.
Ну объясни мне тогда безграмотному как реализовать в MSSQL аналог
IF NEW.ID IS NULL THEN NEW.ID=54677
Причем поле ID NOT NULL.
P.S. Не гоже умному человеку судить о грамотности или безграмотности другого человека только по одному посту, пусть даже и идущему наперекор с твоими убеждениями. А насчет IMHO, так все что я здесь высказал и так есть IMHO, а не истина в последней инстанции, зачем каждый раз добавлять то, что и так само собой разумеется.
| |
Страницы: 