Вообщем, всё больше вижу гуидов в базе в качестве первичных ключей.
Мало того, что их хрен запомнишь или отличишь от похожих, так ещё они сильно больше места занимают (вместе с индексами).

Этого мало. Теперь модно хранить ВНЕШНИИ ключи описывающие тоже самое. Тоже гуиды. И возможно несколько вариантов.
Человек изменивший или создавший запись — гуид. И т.п.

Таблица Product не имеет более id. Она имеет product_id. Чуть-чуть больше чем надо?
А что если, у вас таблица social_engineering_entity_category? Догадываетесь как там называется первичный ключ? social_engineering_entity_category_id!!!

Я уже молчу про 80 символов в строке (макс.) и вертикальное форматирование.

Ну, типа

def test(a: int,
         b: int,
         c: str, 
         d: dict,
         e: Entity
...

У меня экран на 90% пустой!

Здравствуйте, Ватакуси, Вы писали:

В>Вообщем, всё больше вижу гуидов в базе в качестве первичных ключей.
В>Мало того, что их хрен запомнишь или отличишь от похожих, так ещё они сильно больше места занимают (вместе с индексами).
В>...skipped...
В>У меня экран на 90% пустой!

Это не в "Философию" надо, а в КСВ.

Или даже в "COVID-19", как возможное последствие то ли перенесённого заболевания, то ли вакцинации.

Здравствуйте, Ватакуси, Вы писали:

В>Вообщем, всё больше вижу гуидов в базе в качестве первичных ключей.
В>Мало того, что их хрен запомнишь или отличишь от похожих, так ещё они сильно больше места занимают (вместе с индексами).

Недавно проектировал новый сервис, думал над этим вопросом. Всё же решил остаться на числовых id. Как ни крути, а компактность решает. GUID-ы будут замедлять все аспекты СУБД. Да и сортировка по id это удобно. Считаю, что GUID-ы однозначно оправданы в распределённых системах, где несколько однотипных СУБД.

В>Этого мало. Теперь модно хранить ВНЕШНИИ ключи описывающие тоже самое. Тоже гуиды. И возможно несколько вариантов.

Ну внешний ключ-GUID это нормально, если нужно. Конечно если он уже есть — то спорно, но в целом ничего плохого не вижу, по нему будет один индекс и всё, это ерунда.

В>Таблица Product не имеет более id. Она имеет product_id. Чуть-чуть больше чем надо?

Я просто id называю. Не очень понимаю, зачем эти префиксы. Если нужно — в запросе квалифицируешь — product.id и всё. Но в целом тут нет ничего нового, такой стиль давным давно встречался.

В>Я уже молчу про 80 символов в строке (макс.) и вертикальное форматирование.

80 маловато, я для себя 120 стандартом держу.

В>У меня экран на 90% пустой!

Сделай шрифт побольше. Ну или не хвастайся своим зрением (: У меня вот около 140 символов на 27" со всеми закрытыми боковыми панелями.

Здравствуйте, Ватакуси, Вы писали:

В> Вообщем, всё больше вижу гуидов в базе в качестве первичных ключей.
В> Мало того, что их хрен запомнишь или отличишь от похожих, так ещё они сильно больше места занимают (вместе с индексами).

А что именно тебя удивляет? Для маленьких баз замена int на uuid никакого влияния на производительность не оказывает. Для больших баз уже никаких int быть не должно. Другими словами, использовать сейчас int в качестве pk — это или глупость или целенаправленная отложенная диверсия.

Здравствуйте, vsb, Вы писали:

vsb>Недавно проектировал новый сервис, думал над этим вопросом. Всё же решил остаться на числовых id. Как ни крути, а компактность решает. GUID-ы будут замедлять все аспекты СУБД.

Вот это мне, кстати, не совсем понятно. Если я правильно понимаю, GUID обычно хранится как текстовая строка. Сравнивать числа, представленные в виде текстовой строки, на <> не очень удобно и не быстро.
А между тем это 128 битное целое. И сравнение 128-битных целых на <> в 64-битном коде ничем не отличается от сравнения 64-битных целых в 32-битном коде, а это еще в прошлом веке вполне умели, и ненамного это медленнее было сравнения 32-битных целых.

В MS SQL вроде есть тип guid, и представляют в виде 16-байтного массива. В MySQL не видел ничего подобного.


>Да и сортировка по id это удобно. Считаю, что GUID-ы однозначно оправданы в распределённых системах, где несколько однотипных СУБД.

Есть и еще один фактор — UNION. Вот тут описано

https://www.sqlshack.com/understanding-the-guid-data-type-in-sql-server/

vsb>80 маловато, я для себя 120 стандартом держу.

Нарушаешь обратную совместимость. А если придется обратно на перфокарты переходить ?

Здравствуйте, Pavel Dvorkin, Вы писали:

vsb>>Недавно проектировал новый сервис, думал над этим вопросом. Всё же решил остаться на числовых id. Как ни крути, а компактность решает. GUID-ы будут замедлять все аспекты СУБД.

PD>Вот это мне, кстати, не совсем понятно. Если я правильно понимаю, GUID обычно хранится как текстовая строка. Сравнивать числа, представленные в виде текстовой строки, на <> не очень удобно и не быстро.
PD>А между тем это 128 битное целое. И сравнение 128-битных целых на <> в 64-битном коде ничем не отличается от сравнения 64-битных целых в 32-битном коде, а это еще в прошлом веке вполне умели, и ненамного это медленнее было сравнения 32-битных целых.

Конечно GUID-ы хранятся как 128-битные числа или как 16-байтовые массивы, хранить их в виде строк это уже совсем за гранью добра и зла.

Вопрос не в сравнении, а во всём остальном. Хранение индексов для первичного ключа, хранение индексов для foreign key. Это всё раздувает оперативную память, вытесняет кеши и тд.

PD>В MS SQL вроде есть тип guid, и представляют в виде 16-байтного массива. В MySQL не видел ничего подобного.

Ну я постгресом в основном пользуюсь. В нём есть встроенный тип uuid, с которым работаешь, как со строкой, а он преобразовывает всё как надо.

vsb>>80 маловато, я для себя 120 стандартом держу.

PD>Нарушаешь обратную совместимость. А если придется обратно на перфокарты переходить ?

Да как-то сейчас по-другому код пишут. На C всё кратко пишут. mkdir. А на Java — Files.createDirectory. Хочешь-не хочешь, а оно раздувает строки, а сокращать как-то странно уже кажется.

Хотя я видел код, написанный в таком вертикальном стиле. Практически каждая функция писалась в виде

    someFunc(
        arg1,
        arg2
    )

вот он в 80 символов влезал. Но зато по вертикали раздувался — дай боже. Там, где у меня будет 15 строк, влезающих на полэкрана, тут будет 60 на 2 экрана. Мне не понравилось.

Здравствуйте, vsb, Вы писали:

vsb>Конечно GUID-ы хранятся как 128-битные числа или как 16-байтовые массивы, хранить их в виде строк это уже совсем за гранью добра и зла.

Хм.

UUID() returns a value that conforms to UUID version 1 as described in RFC 4122. The value is a 128-bit number represented as a utf8 string of five hexadecimal numbers in aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee format:

https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_uuid

Здравствуйте, Pavel Dvorkin, Вы писали:

PD> В MS SQL вроде есть тип guid, и представляют в виде 16-байтного массива. В MySQL не видел ничего подобного.

Для MySQL есть тип BINARY, где сравнение идет без учета локали (comparison and sorting are based on the numeric values of the bytes in the values). В такое поле можно записать uuid в представлении по любой базе — как строковый hex, так и baseX, так и в чисто бинарном (но это уже не удобно).

Особенность MySQL здесь только в том, что для эффективной интенсивной вставки данных твои id должны быть монотонно возрастающими. Впрочем, это должно быть справедливо для любой БД, а в MySQL на это просто чаще наступают.

Здравствуйте, Pavel Dvorkin, Вы писали:

vsb>>Конечно GUID-ы хранятся как 128-битные числа или как 16-байтовые массивы, хранить их в виде строк это уже совсем за гранью добра и зла.

PD>Хм.

PD>UUID() returns a value that conforms to UUID version 1 as described in RFC 4122. The value is a 128-bit number represented as a utf8 string of five hexadecimal numbers in aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee format:

PD>https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_uuid

За MySQL ничего не скажу, скептически к ней отношусь, не понимаю смысла её существования при наличии постгреса.

Здравствуйте, Anton Batenev, Вы писали:

AB>Другими словами, использовать сейчас int в качестве pk — это или глупость или целенаправленная отложенная диверсия.

Почему? Какие проблемы могут появиться?

Здравствуйте, Буравчик, Вы писали:

Б> AB>Другими словами, использовать сейчас int в качестве pk — это или глупость или целенаправленная отложенная диверсия.
Б> Почему? Какие проблемы могут появиться?

На всякий случай disclaimer — под int я понимаю типичный autoincrement uint64, потому как uuid (да и любая другая последовательность байт) — это тоже int, просто другой разрядности.

Поскольку возможности апгрейда одного физического юнита конечны (апгрейд начинает стоить несоизмеримых денег, если вообще физически возможен), в какой-то момент ты упираешься в производительность железного юнита на запись и тебе становится нужна возможность разделить запись между множеством физических юнитов. Какое-то время здесь может помочь шардирование, но и его возможности конечны.

Т.е. рано или поздно у тебя появляется необходимость создания уникального id любым физическим юнитом независимо от других и типичный autoincrement int здесь не подходит, т.к. является единой точкой блокировок и отказов — для обхода этого ограничения и должна быть использована концепция uuid (хотя, конечно, следовать каноническому RFC для его генерации совершенно не обязательно, если ты знаешь что ты делаешь и можешь гарантировать уникальность).

Вторая проблема больше организационная, нежели техническая и связана с тем, что когда у тебя pk выглядит как int, инкрементится как int, и сравнивается как int, то большинство потребителей твоей информационной системы хардкорно заложатся на то, что это int, даже если в документации (которую традиционно никто не читает) красным жирным шрифтом будет написано обратное.

Т.е. когда ты вдруг решишь перейти с int на uuid, то внезапно обнаружится, что ты не можешь просто так взять и проапдейтить схему в базе, а это проект на годы исправления как собственного legacy, так и "упрашивания" твоих потребителей, которым это исправление нафиг не нужно и у них своих задач хватает. Плюс по прежнему остается открытым вопрос — а сможешь ли ты физически сделать апдейт схемы базы на имеющихся у тебя железных ресурсах?

И, наконец, третье — диапазон uint64 хоть и велик, но все же конечен и в современных реалиях высоконагруженных информационных систем он кончается совершенно неожиданно и внезапно. Например потому что в условиях "пожара" кто-то решил начать эмулировать генерацию uuid на базе int и появились "дырки" в последовательности, а о последствиях такого решения думать в тот момент было некогда.

Здравствуйте, Буравчик, Вы писали:

AB>>Другими словами, использовать сейчас int в качестве pk — это или глупость или целенаправленная отложенная диверсия.

Б>Почему? Какие проблемы могут появиться?

Из очевидных проблем

1. генерация id на клиенте. Зачастую сейчас объекты создаются прямо на клиенте (в браузере например). Для int это тупо невозможно.
2. репликация или шардирование. как разбивать объекты на несколько баз без пересечений по id, как мержить две реплики (особенно актуально если поле автоинкремент — тогда вообще ппц)

Здравствуйте, Anton Batenev, Вы писали:


AB>И, наконец, третье — диапазон uint64 хоть и велик, но все же конечен и в современных реалиях высоконагруженных информационных систем он кончается совершенно неожиданно и внезапно. Например потому что в условиях "пожара" кто-то решил начать эмулировать генерацию uuid на базе int и появились "дырки" в последовательности, а о последствиях такого решения думать в тот момент было некогда.

Реально были случаи когда девять квинтилионов не хватило?

Здравствуйте, Константин Б., Вы писали:

КБ> Реально были случаи когда девять квинтилионов не хватило?

Да, но как я писал они возникли из за "дырок" в генерации последовательности. Потом пришлось чуть ли не вручную восстанавливать пропущенные диапазоны и как-то пытаться их переиспользовать, чтобы это не сильно било по производительности и не требовало переписывания кучи кода. Если бы изначально спроектировали на базе uuid-подобной последовательности, то проблем бы никаких не возникло.

Здравствуйте, Ватакуси, Вы писали:

В>Вообщем, всё больше вижу гуидов в базе в качестве первичных ключей.
В>Мало того, что их хрен запомнишь или отличишь от похожих, так ещё они сильно больше места занимают (вместе с индексами).

В>Этого мало. Теперь модно хранить ВНЕШНИИ ключи описывающие тоже самое. Тоже гуиды. И возможно несколько вариантов.
В>Человек изменивший или создавший запись — гуид. И т.п.

А если ключ делать составным из двух GUID, где — один — GUID ноды с базой, то можно легко мержить базы. Удобнейшая штука

M>А если ключ делать составным из двух GUID, где — один — GUID ноды с базой, то можно легко мержить базы. Удобнейшая штука

А ещё можно одну базу.

AB>>>Другими словами, использовать сейчас int в качестве pk — это или глупость или целенаправленная отложенная диверсия.

Б>>Почему? Какие проблемы могут появиться?

bnk>Из очевидных проблем

bnk>1. генерация id на клиенте. Зачастую сейчас объекты создаются прямо на клиенте (в браузере например). Для int это тупо невозможно.
bnk>2. репликация или шардирование. как разбивать объекты на несколько баз без пересечений по id, как мержить две реплики (особенно актуально если поле автоинкремент — тогда вообще ппц)

Как часто ты с эим сталкивался?

Здравствуйте, Ватакуси, Вы писали:

M>>А если ключ делать составным из двух GUID, где — один — GUID ноды с базой, то можно легко мержить базы. Удобнейшая штука

В>А ещё можно одну базу.

И что будешь делать, когда сервак перестанет её тащить?

AB>На всякий случай disclaimer — под int я понимаю типичный autoincrement uint64, потому как uuid (да и любая другая последовательность байт) — это тоже int, просто другой разрядности.

AB>Поскольку возможности апгрейда одного физического юнита конечны (апгрейд начинает стоить несоизмеримых денег, если вообще физически возможен), в какой-то момент ты упираешься в производительность железного юнита на запись и тебе становится нужна возможность разделить запись между множеством физических юнитов. Какое-то время здесь может помочь шардирование, но и его возможности конечны.

AB>Т.е. рано или поздно у тебя появляется необходимость создания уникального id любым физическим юнитом независимо от других и типичный autoincrement int здесь не подходит, т.к. является единой точкой блокировок и отказов — для обхода этого ограничения и должна быть использована концепция uuid (хотя, конечно, следовать каноническому RFC для его генерации совершенно не обязательно, если ты знаешь что ты делаешь и можешь гарантировать уникальность).

AB>Вторая проблема больше организационная, нежели техническая и связана с тем, что когда у тебя pk выглядит как int, инкрементится как int, и сравнивается как int, то большинство потребителей твоей информационной системы хардкорно заложатся на то, что это int, даже если в документации (которую традиционно никто не читает) красным жирным шрифтом будет написано обратное.

AB>Т.е. когда ты вдруг решишь перейти с int на uuid, то внезапно обнаружится, что ты не можешь просто так взять и проапдейтить схему в базе, а это проект на годы исправления как собственного legacy, так и "упрашивания" твоих потребителей, которым это исправление нафиг не нужно и у них своих задач хватает. Плюс по прежнему остается открытым вопрос — а сможешь ли ты физически сделать апдейт схемы базы на имеющихся у тебя железных ресурсах?

AB>И, наконец, третье — диапазон uint64 хоть и велик, но все же конечен и в современных реалиях высоконагруженных информационных систем он кончается совершенно неожиданно и внезапно. Например потому что в условиях "пожара" кто-то решил начать эмулировать генерацию uuid на базе int и появились "дырки" в последовательности, а о последствиях такого решения думать в тот момент было некогда.

Для 95% баз это неактуально.

M>>>А если ключ делать составным из двух GUID, где — один — GUID ноды с базой, то можно легко мержить базы. Удобнейшая штука

В>>А ещё можно одну базу.

M>И что будешь делать, когда сервак перестанет её тащить?
Сколько раз такое происходило у тебя?