Прошу прощения за, возможно, глупый вопрос!

Со специфическими тонкостями Firebird`а не знаком (с ней не приходилось работать), поэтому, возможно, что то ускользнуло от меня.
В одной из FB-баз встретил в BI-триггерах код генерации уникального идентификатора записи, который любят использовать многие новички в SQL:
Естественно, никаких блокировок БД/таблицы не производится.
Вот и стало интересно - это корректный код для Firebird`а, или его писал как раз новичек, не задумавшись о последствиях при многочисленных сетевых запросах?

Спасибо!

WildSeryOlegROA,

А с какой СУБД работать приходилось?
Потому что никакой специфики тут нет, один г**код. Который, как верно подмечено, приведёт к коллапсу уже на 1.5 пользователях.Много лет работал (и работаю) с десктопными СУБД, а из SQL - несколько лет с MSSQL и MySQL.
Понимаю, конечно, что для любого разработчика более-менее разбирающегося в SQL, вышеприведенный мною код - мягко говоря, некорректен.
Но, к примеру, в FB есть системные генераторы уникального идентификатора, которых нет в mssql и mysql.
Поэтому и подумал - может и BI-триггеры в Firebird имеют какую-либо специфику (типа неявной блокировки таблицы на время его выполнения)?

Dimitry SibiryakovOlegROAв FB есть системные генераторы уникального идентификатора, которых нет в
mssql и mysql.Это какие? Identity, autoincrement и sequences вполне существуют в MS SQL и MySQL, хотя
последние и не очень давно.Классического Firebird генератора уникальных значений sequences, увы, в MySql нет!
Только autoincrement, которого иногда недостаточно.
Можно, конечно, эмулировать его автоинкрементируемым полем в отдельной таблице, но это уже другая тема.

ТаблоидOlegROAМного лет работал (и работаю) с десктопными СУБДТам тоже НИКОГДА нельзя полагаться на max(id).Можно, можно! Естественно, только в режиме полной блокировки рабочей таблицы. Чего нет, к примеру, в MySql.

ТаблоидЕсли у вас много лет получение нового Id идёт через max(...) и не случалось "странных дубликатов", то... всем бы так везло!Еще раз - такой алгоритм использую только в десктопных базах и только в режиме блокировки таблицы. А в SQL (mssql и mysql) использую, естественно, автоинкрементное поле. Но лично мне иногда в mysql не хватает классического sequences Firebird`а!

Ivan_PisarevskyOlegROAМожно, можно!Давайте не будем пропагандировать говнокод и разжигать флуд на этом.
Спасибо за понимание.Прочтите, пожалуйста, все обсуждение прежде, чем делать подобные заявления!
Мой ответ касается алгоритма определения уникального идентификатора в десктопных базах, где нет серверной части и, соответственно, нет вообще такого понятия, как поля-автоинкременты и прочие SQL-вкусности!
Поэтому в таких базах вся логика генерации уникального идентификатора реализуется исключительно в клиентской программе и основана ТОЛЬКО на одном из двух алгоритмах:
1. блокировка всей таблицы, получение максимального значения автонумеруемого поля, добавление новой записи с новым ид, разблокировка таблицы.
2. использование отдельной таблицы для генерации уникальных идентификаторов - блокировка всей этой таблицы или только нужной записи (если движек БД умеет это делать - не все настольные БД это умеют), считывание текущего значения нужного счетчика, увеличение значение, апдейт нового значения, разблокировка записи или таблицы.
Других корректных алгоритмов для этих БД не придумали!

Для общего развития, так сказать - не все СУБД имеет смысл делать на SQL-серверах.
Именно для таких СУБД используются "десктопные" базы, которые представляют собой всего лишь хранилища данных.
Вся обработка в таких базах производится клиентской программой, которая использует библиотеки для работы с такими хранилищами. Это, к примеру, базы форматов dBase, Clipper, FoxPro, Btrieve, Clarion, Topspeed и подобные.
Эти базы не являются анахронизмом и используются не менее интенсивно, чем SQL-сервера.

В общем, если есть интерес то почитайте.
Я же заканчиваю это обсуждение, т.к. с помощью здешних знатоков узнал все, что хотел узнать по вопросу этого топика.
За что им большое спасибо!