Форум MySQL

Вопрос странный, своеобразный, простой, отчасти глупый, но меня очень любопытствующий.

Вот вы когда создаёте на своих сайтах новые сообщения в чате или гостевых, темы в ваших форумах, регистрируете новых пользователей вы, скорее всего, присваиваете этим новым элементам id (идентификатор), ну, или что-нибудь наподобии того.

Вот мне интересно, по какому алгоритму вы ведёте их счёт? Т.е. как определяете, какой новый номер стоит присвоить, почему именно такой.

Мне не нужно ваших кодов, пусть это останется вашим секретом, но вот в общих словах было бы интересно послушать.

Собственно базы данных предоставляют механизм, который позволяет присваивать сообщениям уникальные значения - вот этим механизмом почти все и пользуются. Первому по времени сообщению присваивается 1, второму на единицу больше, т.е. 2 и т.д.

Хорошо, а если одно из сообщений удалить?

Будет пропуск.

А как быть, если сообщения добавлены в абсолютно одно и тоже время (например, 1297854600)?

Ничего страшного, привязка же не по времени идет, а по уникальному id, база данных с этим справляется - она просто всех в очередь ставит и каждый из них получит уникальный номер, ко времени совершенно не привязанный.

Одновременно пришедшие запросы так или иначе встанут в очередь на исполнение, и исполнены будут последовательно.
Номера AUTO_INCREMENT выдаются не по времени исполенения запроса, а в порядке создания записи. Так что одинаковых номеров не будет всяко.

А я почему-то никогда не пользовался AUTO_INCREMENT. Может не привык. На базы перешёл с файлов, так делаю по старинке: содержу файл, в котором прописывается номер и каждый раз его увеличиваю.

В одном из проектов я использовал время поступления в микросекундах.

Ну, это тоже как выход, но опять же не исключает риска одновременного выполнения одного действия двумя пользователя?

Если посещаемость интенсивная, не исключает.

Разрешение у сервера более одной микросекунды, так что, как мне кажется, совпадение технически невозможно.

Разве не так?

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

>Разрешение у сервера более одной микросекунды, так что, как мне кажется, совпадение технически невозможно.
>Разве не так?

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

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

Вот и получается, что выгоды от применения времени в качестве ключа - никакой.
А потери есть.

С другой стороны, применение механизма AUTO_INCREMENT в качестве суррогатного первичного ключа никто не навязывает. Если Вы хотите применять метку времени (или еще что-то) - Вы вполне можете так поступить.
Вот только будет ли профит...

Совершенно с Вами согласен.

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

PS Собственно пользоваться механизмом AUTO_INCREMENT до неприличия просто, нужно просто назначить этот атрибут столбцу и передавать в каждой новой записи значение NULL - уникальные значения будет присваиваться автоматически. Если это значение нужно сразу после добавления запроса, его можно получить при помощи функции mysql_insert_id().

А можно тогда ещё вопрос такой, этот AUTO_INCREMENT начинает нумерацию с нуля или единицы? И он будет увеличивать каждый раз число, даже если последняя запись была удалена?

По умолчанию с единицы, но вы можете назначить в качестве начала - любое произвольное число (либо в операторе CREATE TABLE, либо потом при помощи ALTER TABLE).

А при записи новой INSERT INTO что нужно указывать для этого поля?

Просто NULL

> И он будет увеличивать каждый раз число, даже если последняя запись была удалена?

Именно так.
Механизм ориентируется не на последнюю имеющуюся запись, а на последнее выданное число.
Его, конечно, тоже можно поменять - явным запросом.
Но это будет означать, что администратор сам желает изменить последовательность выдачи.
Более того, поменять его на число меньше, чем уже имеющийся первичный ключ в таблице, ему просто не дадут.

Всех благодарствую.

Я привык к файлам, и потому использовал именно их. Создал функцию, для простого назначения нового id, но новый вариант действительно упрощает жизнь. Что ж, перейду тогда на него. Я немного его потестировал и мне понравился результат.

Спасибо.

То ли еще будет.
Переход с файлов на базу данных открывает колоссальные возможности.

Вячеслав выше сообщал, что на базу данных он перешел, только механизм AUTO_INCREMENT до сих пор предпочитал не использовать.

Верно, уже несколько лет как )

Появился правда ещё один вопрос, я им сам задался щас, когда решил сменить некоторые запросы к базе данных с учётом нововведений и сразу же столкнулся с такой проблемой: раньше-то я заранее знал, какой id будет записан, потому как сначала генерировал его, а уж потом использовал. Сейчас же получится наоборот. Я сначала его запишу, а потом мне нужно узнать какой он. Я так понял мне поможет mysql_insert_id, но вот загвоздка — точно ли mysql_insert_id возвратит мне последний созданный id или могут быть проблемы при большом количестве запросов одновременно?

>точно ли mysql_insert_id возвратит мне последний созданный id или могут быть проблемы при
>большом количестве запросов одновременно?
Точно. Дело в том, что mysql_insert_id() возвращает только тот номер, который был вставлен в рамках текущей сессии, т.е. между INSERT-запросом и вызовом mysql_insert_id() может успеть вставиться еще пяток запросов, но вам будет возвращен номер того, который вставлялся именно вашим запросом.

Ваши слова меня успокоили. Благодарю, Игopь Вячecлaвoвич.