Генерация уникального ID в MySQL

[Energizer]

Генерация уникального ID в MySQL

Что лучше: AUTO_INCREMENT или max(id)+1?

1) Если AUTO_INCREMENT, то как узнать индекс по которому будет добавлена запись?
2) Если max(id)+1, то как защититься от коллизий? Потому как за время между запросами Select max(id)+1 и Insert ... where id=$max_id параметр $max_id может измениться.

 

[Demiurg]

auto_increment лучше, id узнавай после добавления.

 

[Апельсин]

> Если AUTO_INCREMENT, то как узнать индекс по которому будет добавлена запись?

чего????!!!
в смысле узнать номер который будет сгенерен?
и зачем тебе это?

> Если max(id)+1, то как защититься от коллизий? Потому как за время между запросами Select max(id)+1 и Insert ... where id=$max_id параметр $max_id может измениться.

вот именно поэтому автоинкремент предпочтительней ..
а так только лочить всю таблицу.

 

[tony2001]

[m]mysql_insert_id[/m]

 

[Energizer]

Автор оригинала: tony2001
[m]mysql_insert_id[/m]

Там постоянно будут работать ALTER запросы в перемешку с Insert.

 

[Serega]

Дамы и господа, есть вопрос:
несколько пользователей одновременно выполняют INSERT ...
у каждого после этого выполняется mysql_insert_id
что в результате мне вернёт mysql_insert_id, если
при добавлении мной записи в таблицу, автоинкрементное поле сгенерилось, например, 12345, и в этот же момент другой пользователь добавил запись с автоинкрементным полем 12346.

 

[Апельсин]

> Там постоянно будут работать ALTER запросы в перемешку с Insert.

ну и что?

 

[tony2001]

1. и что теперь ?
2. постоянные Альтер - это ОЧЕНЬ неправильно.

 

[Energizer]

Автор оригинала: Апельсин
> Если AUTO_INCREMENT, то как узнать индекс по которому будет добавлена запись?

чего????!!!
в смысле узнать номер который будет сгенерен?
и зачем тебе это?

> Если max(id)+1, то как защититься от коллизий? Потому как за время между запросами Select max(id)+1 и Insert ... where id=$max_id параметр $max_id может измениться.

вот именно поэтому автоинкремент предпочтительней ..
а так только лочить всю таблицу.

"Лочить" - что это? Ты говоришь про транзакции? Вряд ли мой админ c радостью бросится обновлять MySQL.

 

[Апельсин]

> "Лочить" - что это?
это LOCK TABLES ...

но auto_increment - лучше и грамотней!

> и что теперь ?

Тони, ты читаешь мои мысли шаман ..

 

[Energizer]

Автор оригинала: tony2001
1. и что теперь ?
2. постоянные Альтер - это ОЧЕНЬ неправильно.

Почему? По-моему это хотябы лучще чем постоянные DELETE.
Как же поступают в таких ситуациях когда одни позиции "устаревают", другие приходят?

 

[Demiurg]

Energizer, опиши задачу, и тебе скажут решение без альтера.

 

[Апельсин]

> Почему? По-моему это хотябы лучще чем постоянные DELETE.
кто тебе сказал такую глупость?
зачем тебе нужно и то и другое?

> Как же поступают в таких ситуациях когда одни позиции "устаревают", другие приходят?

никак, просто генерятся новые уникальные id, для этого auto_increment и предназначен.

 

[tony2001]

Апельсин:
>Тони, ты читаешь мои мысли шаман ..
у Ромика научился телепатировать =)

Энерджайзер:
>Почему? По-моему это хотябы лучще чем постоянные DELETE.
>Как же поступают в таких ситуациях когда одни позиции
>"устаревают", другие приходят?
тебе ОЧЕНЬ плохо.
это БРЕД.

 

[Energizer]

Автор оригинала: Апельсин
> Почему? По-моему это хотябы лучще чем постоянные DELETE.
кто тебе сказал такую глупость?
зачем тебе нужно и то и другое?


> Как же поступают в таких ситуациях когда одни позиции "устаревают", другие приходят?

никак, просто генерятся новые уникальные id, для этого auto_increment и предназначен.

- Мне не нужен DELETE!
- Для меня не желателен(но не критичен) рост ID!
Таблица будет расти до невероятных размеров! (~5000-10000 в сутки)

 

[Demiurg]

Energizer, возьми калькулятор а посчитай .. тебе хватит integera на 1000 лет.

 

[tony2001]

>- Для меня не желателен(но не критичен) рост ID!
почему ?
если не критичен - тебе не все равно ?

>Таблица будет расти до невероятных размеров! (~5000-10000 в сутки)

по скромным подсчетам поля типа BIGINT при этом хватит на 5053902485948 лет (18446744073709551615/(10000*365)).

столько хватит ?

 

[Energizer]

Через 3 года табличка на 11млн. записей, объмом 35 Гб! Когда буду за хостинг платить, тогда мне станет действительно плохо!

 

[tony2001]

мы очень рады, что у тебя такая неоптимизированная система.

 

[Energizer]

Автор оригинала: tony2001
>- Для меня не желателен(но не критичен) рост ID!
почему ?
если не критичен - тебе не все равно ?

>Таблица будет расти до невероятных размеров! (~5000-10000 в сутки)

по скромным подсчетам поля типа BIGINT при этом хватит на 5053902485948 лет (18446744073709551615/(10000*365)).

столько хватит ?

Господа, это не подходит, да и ни к чему!