Сообщение Re[2]: id integer vs uuid от 19.08.2022 17:08
Изменено 19.08.2022 17:11 vsb
Re[2]: id integer vs uuid
Здравствуйте, wildwind, Вы писали:
vsb>>4. Читабельность. Ну тут целые числа однозначно приятней глазу, чем UUID.
W>Если нужен читабельный пользователями ID, лучше завести отдельный ключ, отличный от PK. Даже если PK это такой же int.
Речь про читабельность для программиста/админа. Например я могу сделать select, увидеть там id=12762 и без копипаста напечатать его же в следующем запросе. С UUID это невозможно.
W>И 2.2 и 2.3 можно перебирать/подбирать. Чуть сложнее, чем 1, но вполне успешно.
Сомневаюсь. Даже 32 бита ты не переберёшь, тебя задолго до этого забанит чего-нибудь. В общем это не то, что обычно понимают под перебором.
vsb>>Также есть проблема с реализацией вариантов 2.2 и 2.3, это не слишком часто используемые подходы и возможно придется использовать редкие библиотеки или писать самому. Это не великая проблема, но всё же.
W>Не вижу проблемы. Библиотек полно, и все современные ОС предоставляют подобный сервис.
Ну приведи пример для postgres. Что за современные ОС, у меня alpine linux, что за сервис ты имеешь в виду?
W>Главное помнить, что best practices это не догмы, а рекомендации. Подходы вполне можно совмещать, даже в рамках одной БД.
W>Таблицы-справочники, меняющиеся раз в год, и таблицы-перечисления, на которые ссылается полбазы, вполне могут жить с целочисленными ключами. Особенно если ключи укладываются, скажем, в байт. Проблемы генерации ключа на клиенте (раз в год) их не касаются.
В моём понимании смысл best practices в том, чтобы не отходить от них без существенных причин. Поэтому таблицы справочники точно будут с UUID в такой модели, по крайней мере я не вижу ни одной причины исключать их. А использовать там однобайтовые идентификаторы это каноничный premature optimization. Но в целом, конечно, согласен, если очень надо — без проблем, это не догма.
vsb>>4. Читабельность. Ну тут целые числа однозначно приятней глазу, чем UUID.
W>Если нужен читабельный пользователями ID, лучше завести отдельный ключ, отличный от PK. Даже если PK это такой же int.
Речь про читабельность для программиста/админа. Например я могу сделать select, увидеть там id=12762 и без копипаста напечатать его же в следующем запросе. С UUID это невозможно.
W>И 2.2 и 2.3 можно перебирать/подбирать. Чуть сложнее, чем 1, но вполне успешно.
Сомневаюсь. Даже 32 бита ты не переберёшь, тебя задолго до этого забанит чего-нибудь. В общем это не то, что обычно понимают под перебором.
vsb>>Также есть проблема с реализацией вариантов 2.2 и 2.3, это не слишком часто используемые подходы и возможно придется использовать редкие библиотеки или писать самому. Это не великая проблема, но всё же.
W>Не вижу проблемы. Библиотек полно, и все современные ОС предоставляют подобный сервис.
Ну приведи пример для postgres. Что за современные ОС, у меня alpine linux, что за сервис ты имеешь в виду?
W>Главное помнить, что best practices это не догмы, а рекомендации. Подходы вполне можно совмещать, даже в рамках одной БД.
W>Таблицы-справочники, меняющиеся раз в год, и таблицы-перечисления, на которые ссылается полбазы, вполне могут жить с целочисленными ключами. Особенно если ключи укладываются, скажем, в байт. Проблемы генерации ключа на клиенте (раз в год) их не касаются.
В моём понимании смысл best practices в том, чтобы не отходить от них без существенных причин. Поэтому таблицы справочники точно будут с UUID в такой модели, по крайней мере я не вижу ни одной причины исключать их. А использовать там однобайтовые идентификаторы это каноничный premature optimization. Но в целом, конечно, согласен, если очень надо — без проблем, это не догма.
Re[2]: id integer vs uuid
Здравствуйте, wildwind, Вы писали:
vsb>>4. Читабельность. Ну тут целые числа однозначно приятней глазу, чем UUID.
W>Если нужен читабельный пользователями ID, лучше завести отдельный ключ, отличный от PK. Даже если PK это такой же int.
Речь про читабельность для программиста/админа. Например я могу сделать select, увидеть там id=12762 и без копипаста напечатать его же в следующем запросе. С UUID это невозможно.
W>И 2.2 и 2.3 можно перебирать/подбирать. Чуть сложнее, чем 1, но вполне успешно.
Сомневаюсь. Даже 32 бита ты не переберёшь, тебя задолго до этого забанит чего-нибудь. В общем это не то, что обычно понимают под перебором.
vsb>>Также есть проблема с реализацией вариантов 2.2 и 2.3, это не слишком часто используемые подходы и возможно придется использовать редкие библиотеки или писать самому. Это не великая проблема, но всё же.
W>Не вижу проблемы. Библиотек полно, и все современные ОС предоставляют подобный сервис.
Ну приведи пример для postgres. Что за современные ОС, у меня alpine linux, что за сервис ты имеешь в виду?
W>Главное помнить, что best practices это не догмы, а рекомендации. Подходы вполне можно совмещать, даже в рамках одной БД.
W>Таблицы-справочники, меняющиеся раз в год, и таблицы-перечисления, на которые ссылается полбазы, вполне могут жить с целочисленными ключами. Особенно если ключи укладываются, скажем, в байт. Проблемы генерации ключа на клиенте (раз в год) их не касаются.
В моём понимании смысл best practices в том, чтобы не отходить от них без существенных причин. Поэтому таблицы справочники точно будут с UUID в такой модели, по крайней мере я не вижу ни одной причины исключать их. А использовать там однобайтовые идентификаторы это каноничный premature optimization, который с очень ощутимой вероятностью выстрелит лет через 5, когда придётся делать миграцию половины таблиц на более широкий тип. Но в целом, конечно, согласен, если очень надо — без проблем, это не догма.
vsb>>4. Читабельность. Ну тут целые числа однозначно приятней глазу, чем UUID.
W>Если нужен читабельный пользователями ID, лучше завести отдельный ключ, отличный от PK. Даже если PK это такой же int.
Речь про читабельность для программиста/админа. Например я могу сделать select, увидеть там id=12762 и без копипаста напечатать его же в следующем запросе. С UUID это невозможно.
W>И 2.2 и 2.3 можно перебирать/подбирать. Чуть сложнее, чем 1, но вполне успешно.
Сомневаюсь. Даже 32 бита ты не переберёшь, тебя задолго до этого забанит чего-нибудь. В общем это не то, что обычно понимают под перебором.
vsb>>Также есть проблема с реализацией вариантов 2.2 и 2.3, это не слишком часто используемые подходы и возможно придется использовать редкие библиотеки или писать самому. Это не великая проблема, но всё же.
W>Не вижу проблемы. Библиотек полно, и все современные ОС предоставляют подобный сервис.
Ну приведи пример для postgres. Что за современные ОС, у меня alpine linux, что за сервис ты имеешь в виду?
W>Главное помнить, что best practices это не догмы, а рекомендации. Подходы вполне можно совмещать, даже в рамках одной БД.
W>Таблицы-справочники, меняющиеся раз в год, и таблицы-перечисления, на которые ссылается полбазы, вполне могут жить с целочисленными ключами. Особенно если ключи укладываются, скажем, в байт. Проблемы генерации ключа на клиенте (раз в год) их не касаются.
В моём понимании смысл best practices в том, чтобы не отходить от них без существенных причин. Поэтому таблицы справочники точно будут с UUID в такой модели, по крайней мере я не вижу ни одной причины исключать их. А использовать там однобайтовые идентификаторы это каноничный premature optimization, который с очень ощутимой вероятностью выстрелит лет через 5, когда придётся делать миграцию половины таблиц на более широкий тип. Но в целом, конечно, согласен, если очень надо — без проблем, это не догма.