|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Andrey 2:5083/13.5 01 Apr 2001 13:03:16
To : Drema*
Subject : Дремина хитрость 2
--------------------------------------------------------------------------------
Hi! Drema*
> D> UPDATE ID_ SET @ID=ID=ID+1
> Дрема вот это и есть конкретное ламерство, тут тебя не сможет развести
>ни один,даже самый мудрый сервер. Потому как даже строчная блокировка не
>спасает от совершенно ненужной задержки пользователей работающих с вообще
>никак не пересекающимися таблицами.Дрема,ты сам не понятно зачем организовал
>узкое место в своей системе. Или же ты таким вот образом вылечил MS-SQL от
>необходимости при его спотыканиях запускать checkident :))))). Крут ты Дрема
>однако,кру-у-ут.:)))
D> :) Короче, умник ты наш, зайди вот сюда:
D> http://www.drema.c-net.ru/c_bd_ident.asp,
D> там специально для таких как ты все разжевано...
Как и следовало ожидать, ничего окромя дремучего ламерства я там не
прочел.:)) Во первых как я уже отмечал ты заставив всех пользователей
апдейтить одну и ту же строку в одной и той же таблице, просто выставил
их всех в очередь за следующим значением поля идентификатора. То есть из
худо бедно многопользовательского SQL сервера сделал чисто
однопользовательский. Во вторых отключил проверку на Not Null всех полей
в базе данных в результате понизил защиту от дурака встоенную в SQL сервер
от неполного заполнения полей в форме. Hу и как следствие того,что все поля
должны быть при вставке Null то естественно повысил вероятность появления
сиротских записей,в детальных таблицах. Короче Склифасовский хреновая у тебя
метода,со всех строн хреновая,ни к черту не годится.:))) Кстати скажу тебе
по секрету,что тот же System 11.5 ближайший родственник MS-SQL инкапсулирует
значение поля @@IDENTITY при работе с триггерами, то есть в нормальном SQL
сервере переменная @@IDENTITY всегда хранит идентификатор вставленной записи
в таблицу, вне зависимости от количества инсертов в теле триггере на
инсерт.Вот так вот делают все нормальные SQL сервера.:)))
Так что давай Дрема вертай назад все ключевые поля в таблицах на идентити.
А в таблицах с триггерами на инсерт раз уж ты их так боишся,можешь в теле
триггера на инсерт селектом искать последнюю вставленную запись, и апдейтить
ее на максимальную + 1. А что бы при вставке новой записи сразу двумя
пользователями примерикей не дублировался, вставляй по дефаульту вместо
идентификатора отрицательное значение идентификатора сессии @@SPID * -1.
Hу а если же тебе нужно на клиенте еще некоторое время работать с этой
записью и искать ее по идентификатору,то тогда в теле тригерра его не
трогай, а апдейть на максимальный + 1 с клиента,тогда на клиенте ты точно
будешь знать идентификатор последней вставленной записи. Дрема понял как все
просто и элегантно, а ты тут наворотил тако-о-о-ое,что просто диву даешся
полету твоей фантазии. :))) Вот так вот Дрема надо решать Копеечные
проблемы.:))
Андрей
---
* Origin: (2:5083/13.5)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
