Если нужен автоинкремент по одной таблице то что лучше использовать SEQUENCE, IDENTITY , SERIAL или AUTOINCREMENT?
Допустим я использовал для:
1. MSSQL - IDENTITY
2. MYSQL - AUTOINCREMENT
3. ORACLE - SEQUENCE + trigger
4. FIREBIRD - SEQUENCE + trigger
5. POSTGRESQL - SEQUENCE + trigger (но он же поддерживает и SERIAL)
Кстати, в чем различие IDENTITY, SERIAL и AUTOINCREMENT?

Чем от них отличается SEQUENCE понятно - это сквозная нумерация по 1 и более таблиц, но чем он лучше остальных способов не понятно и не очень красиво выглядит триггер с ним на каждую таблицу.

SEQUENCE MS SQLавторДопустим я

1. MSSQL - SEQUENCE + DEFAULT CONSTRAINT

авторпо одной таблице ... на каждую таблицу

Вы, уж, определитесь в постановке задачи...
http://msdn.microsoft.com/en-us/library/ff878091(v=SQL.110).aspx
SEQUENCE появиться только в SQL Server 2012. И что значит DEFAULT CONSTRAINT? В SQL Server 2012 можно будет SEQUENCE писать в DEFAULT и он сам будет автоинкремениться при инсертах?
К слову в Oracle, Firebird и PostgreSQL так сделать нельзя, нужен обязательно триггер.

Постановки задачи как таковой нет - есть необходимость разобраться в каком случае что лучше?

Andron , вполне логично. А насколько скорость serial отличается от аналогичной через SEQUENCE + trigger или SEQUENCE в INSERT-запросе?

softwarerkdvя понимаю, что это все разные методы использования генераторов. Но не понимаю, зачем разработчику потребовалось городить такую кашу.
Не понимаете - значит, вполне вероятно, зря городил. С другой стороны, например, в первый раз я отступил от принятой в конторе практики генерации id в триггерах, когда требовалось массово грузить в приложение некие данные со стороны, и отказ от этих триггеров увеличил скорость загрузки в пять-десять раз. Полагаете, был неправ?
1. Отключили триггеры и импользовали SEQUENCE в инсертах?
2. Или вообще отказались от SEQUENCE?

softwarerSEQUENCE vs IDENTITY1. Отключили триггеры и импользовали SEQUENCE в инсертах?
2. Или вообще отказались от SEQUENCE?
Отключил триггеры, сделал сиквенсам increment by 1000 и формировал данные для direct load-а.
Т.е. в интервалах по 1000 нумеровали уже сами?
А установить кэш не пробовали ALTER SEQUENCE seq CACHE 2000; или вообще нумеровать самому без сиквенсов через оконные функции?

softwarerSEQUENCE vs IDENTITYА установить кэш не пробовали
А смысл? Кэш регулирует быстродействие сервера, а целью в данном случае было избежать огромного количества тупых синхронных запросов к серверу "за айдишниками".
Это что за синхронные запросы к сервер? Или ты имеешь ввиду сначала получать ID из синквенса с сервера, затем его вставлять в запрос, а затем отправлять запрос на сервер?

Нафига такое счастье, когда можно так:


И посылай значения NAME пачками.
Или по аналогии без параметризованного запроса.

softwarerSEQUENCE vs IDENTITYили вообще нумеровать самому
А нафига такое счастье?
Это аналогично:
"Отключил триггеры, сделал сиквенсам increment by 1000000000 и формировал данные для direct load-а." Т.е. вообще о сиквенсе париться не надо.

softwarerSEQUENCE vs IDENTITYНафига такое счастье, когда можно так:
[src PLSQL]
INSERT INTO table (ID, NAME) VALUES(SEQ.NEXT_VAL, :NAME)
Затем, что хотелось не "так", а "быстро".
Если быстро то без сиквенса, если удобно то с кэшем сиквенса, а если "быстро", то с инкрементом 1000.

Warstonesoftwarerпропущено...

А смысл? Кэш регулирует быстродействие сервера, а целью в данном случае было избежать огромного количества тупых синхронных запросов к серверу "за айдишниками".Ну вообще-то немного не так... Если я правильно помню, то кеш как-раз говорит о том, что за одну синхронизацию "за id'ами" выберется вот тот 1К id'ов и больше синхронизироваться не надо будет (до тех пор, пока в текущей транзакции id'ы не закончатся.

Так что кеш генератора в данном случае как-раз и должен был решить вашу проблему. Но это в теории. Как это на практике (кстати, что за СУБД, на M$-ли?) в вашей СУБД - не знаю.
Вы все проспали. Речь шла о СУБД Oracle.
Ни с кэшем ни без него никаких синхронных запросов за ID-шниками не будет. Откуда это взял softwarer непонятно. ID-шники беруться непосредственно при выполнении инсерта.
Без кэша сиквенса будут постоянные межядерные пинги процессорного кэша, с кэшэм сиквенса они будут в 1000 раз реже. Вот в чем проблема, которую softwarer решил в ручную вместо простой комманды.

Ну а вместо использования в ручную нелогируемых параметризованных инсертов с аппендом и группировкой по транзакциям, он использовал автоматизированный и равный по производительности direct load.