|
|
|
Генерация собственного уникального идентификатора записи
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток, комрады. Стоит следующая задача: нужно генерировать для каждой записи в БД уникальный ИД, по которому так же можно определить к какой таблице он относится. Генерировать буду хранимой процедурой MySQL, чтобы не создавать по два запроса в PHP. ИД будет настраиваемый по длине и состоит из латинский букв и чисел (1-0 A-Z a-z), причем первых два символа это будет ИД таблицы, например PR0001Qf, PR0001Qg, PR0001Qh. От генерации по UUID() отказался т.к. слишком большая длина, а UUID_SHORT() имеет ограничение уникальности при server_id > 255 и другие недостатки. 1. Но, что же получается, мне что нужно перед каждым INSERTом лочить таблицу на чтение и запись? Ведь теоретически в промежуток времени, между началом генерации нового ИД и вставкой его в таблицу, второй клиент может так же попробовать сгенерировать новый ИД, который будет не уникальным. Как избежать коллизий? 2. Как получить идентификатор вставленной записи? Как вариант вижу делать все вставки через хранимые функции MySQL, но не хочется. Интересуют так же ваши мысли по поводу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2013, 12:51:53 |
|
||
|
Генерация собственного уникального идентификатора записи
|
|||
|---|---|---|---|
|
#18+
bigint unsigned для каждой таблицы auto_increment x где х -1, -2, -3 и так далее. это будет id таблицы все остальное работает как обычно чтобы получить id таблицы надо замаскировать старший байт id любой записи. Это значит таблиц не может быть больше 254 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2013, 20:51:35 |
|
||
|
Генерация собственного уникального идентификатора записи
|
|||
|---|---|---|---|
|
#18+
Ну, типичная система хранения двух чисел в одном слове. Например старшие 4 бита одно число, младшие 4 другое. Так устроена двоично-десятичная система. Ее можно расширить и сделать так, что в старшем байте одно число, а во всех остальных 7 байтах - другое. Малеькие отрицательные числа удобно юзать чтобы не юзать огромные положительные числа для добавления и маскирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2013, 20:55:32 |
|
||
|
Генерация собственного уникального идентификатора записи
|
|||
|---|---|---|---|
|
#18+
Например для байта, 8 бит, без знака, -1 это 2^8-1, или 254. Для 8 байт, bigint, соответственно 2^64-1 или... посчитайте на калькуляторе. 8) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2013, 20:59:28 |
|
||
|
Генерация собственного уникального идентификатора записи
|
|||
|---|---|---|---|
|
#18+
Firmware 1.01bДоброго времени суток, комрады. Стоит следующая задача: нужно генерировать для каждой записи в БД уникальный ИД, по которому так же можно определить к какой таблице он относится. Генерировать буду хранимой процедурой MySQL, чтобы не создавать по два запроса в PHP. ИД будет настраиваемый по длине и состоит из латинский букв и чисел (1-0 A-Z a-z), причем первых два символа это будет ИД таблицы, например PR0001Qf, PR0001Qg, PR0001Qh. От генерации по UUID() отказался т.к. слишком большая длина, а UUID_SHORT() имеет ограничение уникальности при server_id > 255 и другие недостатки. 1. Но, что же получается, мне что нужно перед каждым INSERTом лочить таблицу на чтение и запись? Ведь теоретически в промежуток времени, между началом генерации нового ИД и вставкой его в таблицу, второй клиент может так же попробовать сгенерировать новый ИД, который будет не уникальным. Как избежать коллизий? 2. Как получить идентификатор вставленной записи? Как вариант вижу делать все вставки через хранимые функции MySQL, но не хочется. Интересуют так же ваши мысли по поводу. как часто говорят - хочешь помощи, ПРЕЖДЕ ВСЕГО - опиши задачу а не свой способ решения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2013, 01:03:54 |
|
||
|
Генерация собственного уникального идентификатора записи
|
|||
|---|---|---|---|
|
#18+
alex564657498765453Firmware 1.01bДоброго времени суток, комрады. Стоит следующая задача: нужно генерировать для каждой записи в БД уникальный ИД, по которому так же можно определить к какой таблице он относится. ... как часто говорят - хочешь помощи, ПРЕЖДЕ ВСЕГО - опиши задачу а не свой способ решения. [quot Firmware 1.01b] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2013, 07:39:04 |
|
||
|
Генерация собственного уникального идентификатора записи
|
|||
|---|---|---|---|
|
#18+
debloggerbigint unsigned для каждой таблицы auto_increment x где х -1, -2, -3 и так далее. это будет id таблицы все остальное работает как обычно чтобы получить id таблицы надо замаскировать старший байт id любой записи. Это значит таблиц не может быть больше 254 Спасибо, отличный вариант, единственное - не наглядно и в GET запросе будут монстры типа /?city=71776119061217531&orderid=70368744177671669 И еще момент, когда пользователь TRUNCATEнет таблицу, AI сбрасывается. Установить начальное значение AI он не сможет, а очень хочется, чтобы все было юзер френдли:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2013, 07:56:32 |
|
||
|
Генерация собственного уникального идентификатора записи
|
|||
|---|---|---|---|
|
#18+
Firmware 1.01bИ еще момент, когда пользователь TRUNCATEнет таблицу, AI сбрасывается. Установить начальное значение AI он не сможет, а очень хочется, чтобы все было юзер френдли:)Прикольный интерфейс... Операция TRUNCATE TABLE - лучший друг пользователя ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2013, 09:38:53 |
|
||
|
Генерация собственного уникального идентификатора записи
|
|||
|---|---|---|---|
|
#18+
=)8), в интерфейсе не будет TRUNCATE, просто есть вероятность, что пользователь так сделать через ПМА. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2013, 12:52:16 |
|
||
|
Генерация собственного уникального идентификатора записи
|
|||
|---|---|---|---|
|
#18+
Firmware 1.01bСпасибо, отличный вариант, единственное - не наглядно и в GET запросе будут монстры типа /?city=71776119061217531&orderid=70368744177671669 А вы их в hex загоните, станет красивее немного. Однако можете выбрать - красивые буковки в урле и геморрой в запросах и процедурах, или наоборот. Все равно будет геморрой, прозрачно же не получится. Кстати, обратите внимание на get у гугля при запросе "проверка". Насколько наглядно? И кто-то парится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2013, 23:15:01 |
|
||
|
|

start [/forum/topic.php?fid=47&gotonew=1&tid=1836365]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
62ms |
get topic data: |
7ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
31ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 343ms |

| 0 / 0 |
