При 10000 пользователей (что маловато будет для Internet-ориентированной системы) INTEGER иссякнет через 5 лет.
Если они творческие личности и склонны к частым изменениям записей(контента), то автоинкремент иссякнет очень быстро. Использование везде и всюду BIGINT снижает производительность.




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




Проще, повесить на триггер AFTER DELETE сохранение удаленного идентификатора в небольшой таблице резерва, а потом, если резерв есть, его оттуда брать. Если в момент сохранения произойдет сбой или атомная война, то максимум что произойдет это потеря одного единственного удаленного значения, что никак не скажется на базе в целом.

JavaCraft, 


А ежели подумать? Здравый смысл применить?


Еще раз: любая попытка вычисления/получения уникального значения идентификатора из приложения, а не путем формирования его сервером, ПРИНЦИПИАЛЬНО источник проблем. Хотя бы по той причине, что приложение не может определить (не)успешность этой операции и произвести откат.

О приложении и речи нет. Всё делает исключительно сервер.
Поле автоинкрементное, но если вставлять запись с инициализированным не NULL значением, то MySQL не выполняет автоинкремент, а использует то значение, которое ему дали.
Это значение берется из таблицы резерва, которая хранится также на сервере.
Выполняет все это хранимая процедура, тоже на сервере. Такая же процедура сбрасывает идентификаторы в резерв, после удаления записей.
Пользователь имеет доступ к базе исключительно через хранимые процедуры и ничем не может навредить базе.

А Вы, как я полагаю, предпочитаете давать юзеру права выполнять SQL запросы INSERT,DELETE,UPDATE... из приложения.   

Вы полагаете выборка значения из таблицы будет быстрее операции с бигинтом?

Добавлено через 1 минуту и 40 секунд
Кроме того при массированом использовании триггеров с хранимками говорить о производительности вообще трудно. Это же интерпретируемые языки которые будут дергаться при любом изменении записи.

Добавлено через 4 минуты и 51 секунду


10000 одновременно работающих пользователей   ? в какой операционке и на каком железе вы собираетесь получить такую нагрузку?

Добавлено через 7 минут и 9 секунд
PS Если вам мало int/bigint - используйте функцию UUID(). Она  для таких целей и создана

В нормальных условиях не быстрее, но BIGINT требует в два раза больше дисковой и оперативной памяти. 
Кроме того, сказали А, должно сказать и В. Во всех таблицах где мы ссылаемся на эту таблицу нам придется перейти на BIGINT. Про индексы забыли? Они тоже удвоятся.
Если памяти не хватит, то таки ДА будет медленнее. Для меня лишние 32Гиг на каждую таблицу и каждое ссылочное поле, приемлемы только в случае если другого пути нет.
А выборка из маленькой таблицы, к томуже закэшированной в памяти, выполняется очень быстро.



На любом, хоть на P1 133Mhz 64RAM. Тут не в нагрузке дело и не в одновременности, а в количестве и качестве "писателей". Достаточно просто раз в 1-10 секунд подключаться и добавлять запись.


Ну не при любом, а при вполне конкретном. AFTER DELETE, BEFORE INSERT
А соотвествующие SP вызываются по мере необходимости. И они компилируются один раз, а не интерпретируются каждый раз, если только Вы под интерпретацией не имеете в виду внутреннюю реализацию скомпилированного кода. Но это же мелочи. Куда тяжелее и дольше взаимодействовать с внешней бизнес логикой.

Это сообщение отредактировал(а) JavaCraft - 3.5.2007, 01:50

JavaCraft, 
Немножко посчитаем. Int - 8, bigint - 16 байт. 32 Гб/8 = 4 Г записей. Если в записи 100 байт - таблица - 400 Гб. 10 таблиц - 4 Тб. Ну в 2 раза меньше, если поле просто добавить. Непринципиально. 
Может сказочки в другом месте будешь рассказывать?


Опять бред. От незнания основ.

И что вы уже этим хотели сказать?
32Гб это увеличение расхода памяти на 4Г проиндексированных записей состоящих из 1 поля. Поуважительнее плиз, просьба не хамить.



Такие реплики признак непрофессионализма, а мнение непрофессионала меня не интересует.

JavaCraft, 
Если не понял, то объясняю: я прикинул размер БД, у которой добавление 1 поля int или изменение с int на bigint увеличивает размер таблицы на 32 Гб. Как автор описал.


А нука подробнее, пример в студию. Как это вычислялось и что за таблица? Только не надо уползать в сторону полнотекстового поиска  и т.п. Речь идет об int/bigint.

2JavaCraft:
"Валик-джан, я тебе один умный вещь скажу, только ты не обижайся", 

- Вы говорите о миллиардах записей, и приводите P1 133Mhz 64RAM в качестве железа. 
- Вас страшит bigint, хотя заполнить обычный unsigned int автоинками еще никому не удавалось. По крайней мере на моей памяти.  
- вы говорите о компиляции хранимок/триггеров. Хотя на самом деле они хранятся в в таблице mysql.proc просто как строки, а кешируются как деревья, и исполняются обходом аттрибутного дерева в памяти. Это чистой воды интерпретация. Иначе вам придется называть и питон и перл компилируемыми языками.

Не обижайтесь, но Вы теоретик.



Это сообщение отредактировал(а) Бонифаций - 3.5.2007, 13:57

На той железке у меня был Web-сайт и летала база с таблицами 8000000 записей, правда всё было на MyISAM, только для чтения и посетителей не много. Этот гратеск не для показа на чем будет крутиться эта база (такое железо сейчас трудно найти), а чтобы было понятно, что от нагрузки в единицу времени тут ничего не зависит. 


В моей задаче UNSIGNED INT будет заполнен очень быстро (чисто теоретически).


не обижаюсь

А вообще парню нужно было решение как заполнить пробелы в идентификаторах и я его кажется дал. Причем это лучшее решение в данной постановке вопроса. Я не утверждаю что оно лучше чем автоинкремент, это несравнимые и совсем разные вещи.

Это сообщение отредактировал(а) JavaCraft - 3.5.2007, 16:55

Бонифаций, 
JavaCraft не теоретик, а обычный "WEB-дизайнер", поперший в СУБД. Не первый и не последний.

JavaCraft, 

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


А вообще если в чем-то не разбираешься совсем, так лучше не советовать. Поскольку получается "лучшее лекарство от насморка - гильотина".

Ну ну. Можно подумать твои посты по всем форумам можно назвать содержательными... 
Везде, где твою писанину встречаю, вижу только хамство и обсерательство.
Подумай на досуге, может тебе к доктору нужно сходить?

JavaCraft, 
Я не хамлю. Нет такой привычки. Просто я на основании своего опыта достаточно быстро определяю что из себя представляет собеседник. И вместо фантазирования использую факты и доки. В отличие от.
Когда новичок предлагает свое "гениальное" решение, которое ПРИНЦИПИАЛЬНО неверно и приведет к проблеме, то этот новичок неправ по крайней мере дважды.

Это решение не ново, широко известно и оно не моё.