AS
думаю что Media Access Control
this
Size: a a a
2021 February 04
I
ну вот да, мне поэтому больше нравится подход когда нет никакого дала, а объект сам за собой следит, get_by_id тогда приобретает смысл что id управляется клиентом и не связан с id в базе данных (и не является PK, что отдельный бонус), а id в базе занимается уже ОРМ или код который вместо него, и он остается деталью реализации, а пользовательский id тоже можно обвешать индексами и сделать быстрым
А как сохранить уникальность пользовательского id если не uuid?
p
this
mac + ts - это так себе
ПМ
https://ru.wikipedia.org/wiki/UUID ну я так понимаю речь шла про uuid первой версии
AS
Ivan
А как сохранить уникальность пользовательского id если не uuid?
а почему не uuid? :) в общем случае завсисит от задачи - какие свойства пользователя его уникально идентифицируют в системе - например логин
ПМ
шанс попасть всё-таки крайне мал
AS
mac + ts - это так себе
почему?
I
а почему не uuid? :) в общем случае завсисит от задачи - какие свойства пользователя его уникально идентифицируют в системе - например логин
ПМ
у тебя там какой-то страшный high load?
OK
Ivan
А как сохранить уникальность пользовательского id если не uuid?
В смысле? Автоинкремент, не?
OK
Ivan
Там вроде речь о том, когда UUID используется как Primary Index, основная айдишка. Это кажется и правда очень странным решением, собственно, делать любую строку primary index это очень странно, производительность на строках же сильно ниже производительности на числах
OK
>When the schema is based on UUID values, all these columns and indexes supporting them are char(36). I recently analyzed a UUID based schema and found that about 70 percent of storage was for these values.
Ну это и козе понятно же, не?
Ну это и козе понятно же, не?
I
В смысле? Автоинкремент, не?
автоинкрементен это в базе, а мы пришли к тому что id сущности управляется клиентом и не связан с id в базе данных
I
Ибо проблема изначальна и была в автоинкрементене, потому что он будет известен только после сохранения в базе
I
А до этого модель будет не консистентная и надо будет его руками добавлять после сохранения
AZ
Там выше Павел задал самый правильный вопрос.
AS
Ivan
автоинкрементен это в базе, а мы пришли к тому что id сущности управляется клиентом и не связан с id в базе данных
автоинкремент не обязательно в базе, хотя его можно сделать через счетчики в базе, используя БД для синхронизации, но кажется что для хайлоада только справедливо
AZ
автоинкремент не обязательно в базе, хотя его можно сделать через счетчики в базе, используя БД для синхронизации, но кажется что для хайлоада только справедливо
Для хайлоада это неприемлимо, потому что появляется точка синхронизации, рушащая распределённость системы.
ПМ
какой-нибудь zookeeper такое делать не умеет?
AZ
Ну т.е. как только появляется одно место, куда ходят все, так оно сразу становится бутылочным горлышком.