АГ
Если только uuid v1, а не v4
какая разница, технически это все uint128
Size: a a a
2021 February 08
АГ
индекс же строится по полю
В
Спроси его про плюсы генерации ID автоинкрементом и задай на эти "плюсы" вопросы, на которые он не сможет ответить, делов то
Было бы здорово где-то набраться мудрости и заранее подготовить формулировки. Я и сам не гуру далеко.
ЕР
Неочевидно, как представить плюсы генерации id в коде тимлиду, который никогда не работал с подобным. Надо кардинально изменить взгляды человека.
Если создавать сущность без айдишки, она:
1. Не валидна, и становится валидной только после сохранения в базе, и имеет nullable поле id, что немного противоречит определению сущности
2. Не может производить действия завязанные на id: продюсить ивенты, создавать новые сущности с общей айдишкой, или банально записать в лог айдишку сущности сразу
1. Не валидна, и становится валидной только после сохранения в базе, и имеет nullable поле id, что немного противоречит определению сущности
2. Не может производить действия завязанные на id: продюсить ивенты, создавать новые сущности с общей айдишкой, или банально записать в лог айдишку сущности сразу
R
какая разница, технически это все uint128
Технически не будет никакого смысла делать > < по полю, которое неупорядоченно
АГ
Технически не будет никакого смысла делать > < по полю, которое неупорядоченно
с первичными ключами такое бывает?
R
с первичными ключами такое бывает?
Ты гуглил cursor pagination?
В
какая разница, технически это все uint128
v4 же рандомен, нет гарантии, что добавляемое значение больше предыдущего
R
Но на самом деле, это не столько проблема. Достаточно добавить поле timestamp и сделать cursor pagination по нему. И сделать на него индекс (лучше кластерный)
SB
Доброго дня.
Кто-нибудь может подкинуть литературу на тему проблем, связанных с использованием автоинкремента в качестве id сущности?
Кто-нибудь может подкинуть литературу на тему проблем, связанных с использованием автоинкремента в качестве id сущности?
Автоинкремент - это штука специфическая для RDBMS. Поэтому ваши сущности оказываются завязаны на БД. Поэтому я тоже голосую за uuid, как вариант наиболее универсальный. Это не отменяет возможности иметь autoincrement primary key, если это удобно или требуется вашим ORM. Why not both?
DT
Можно перкд созданием сущности ходить в бд и дергать сиквенс
R
Можно перкд созданием сущности ходить в бд и дергать сиквенс
Чтобы получить состояние гонки?
DT
Гонки за что?
SP
v4 же рандомен, нет гарантии, что добавляемое значение больше предыдущего
по этой причине есть всякие CUID (https://github.com/ericelliott/cuid) и прочие UUIDv6 (https://tools.ietf.org/html/draft-peabody-dispatch-new-uuid-format-00)
R
Гонки за что?
За последний айдишник
SP
Чтобы получить состояние гонки?
секвенсы гарантируют что значение получит только один. Это ж сиквенсы. Просто в mysql такого нет.
DT
Сиквенс автоинкрементить при запросе
ак
Доброго дня.
Кто-нибудь может подкинуть литературу на тему проблем, связанных с использованием автоинкремента в качестве id сущности?
Кто-нибудь может подкинуть литературу на тему проблем, связанных с использованием автоинкремента в качестве id сущности?
Почему бы хеш не использовать?
SP
в postgresql это просто
select nextval(my_sequence) и нет ни гонок ни проблемDT
Да, главное не текущее значение