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

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

Таблица 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>И что будешь делать, когда сервак перестанет её тащить?
Сколько раз такое происходило у тебя?

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

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

Практически всегда это решается изоляцией базы от клиентов через микросервис.

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

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

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

Как-то постоянно

Практически для любого веб-приложения с которым я сталкивался, первое (необходимость генерации id на сервере) является проблемой.

Разделение базы на несколько, допустим по регионам, или просто создание архива по датам (отдельная база)

Элементарный импорт-экспорт данных в каком-нибудь текстовом формате.
Объекты в экспортируемом файле должны иметь (глобально) уникальный идентификатор, иначе будет каша.
Где они его возьмут, если его нет в базе?

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

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

bnk>Как-то постоянно

bnk>Практически для любого веб-приложения с которым я сталкивался, первое (необходимость генерации id на сервере) является проблемой.
Я вот вообще не уверен, что это здорово — создавать ID на клиенте. Более того, ни разу этого не видел нигде. Для этого есть служба (в монолите или нет — неважно).

bnk>Разделение базы на несколько, допустим по регионам, или просто создание архива по датам (отдельная база).
В век микросервисов вообще непонятно, зачем это может кому-нибудь потребоваться. Базы же маленькие. Если таки у тебя огромная база по каким-то причинам, то для этого есть другие архитектурные решения.

bnk>Элементарный импорт-экспорт данных в каком-нибудь текстовом формате.
bnk>Объекты в экспортируемом файле должны иметь (глобально) уникальный идентификатор, иначе будет каша.
Это почему ещё?

bnk>Где они его возьмут, если его нет в базе?
Понятно, что в базе он должен быть. Только как это связано с гуидами?

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

B>> Я вот вообще не уверен, что это здорово — создавать ID на клиенте. Более того, ни разу этого не видел нигде. Для этого есть служба
В смысле, чтобы создать новый объект, ты делаешь запрос к этой службе что ли?
Тормоза же, плюс поддержка этой никому не нужной службы.

bnk>>Разделение базы на несколько, допустим по регионам, или просто создание архива по датам (отдельная база).
В>В век микросервисов вообще непонятно, зачем это может кому-нибудь потребоваться. Базы же маленькие. Если таки у тебя огромная база по каким-то причинам, то для этого есть другие архитектурные решения.

Так я еще эти микросервисы толком разглядеть не успел, а они вроде уже всё

Автор: BlackEric
Дата: 22.11.21

?

bnk>>Где они его возьмут, если его нет в базе?
В>Понятно, что в базе он должен быть. Только как это связано с гуидами?

Не понял. Мы же и говорим про базу. Что он должен там быть. Гуид.

B>>> Я вот вообще не уверен, что это здорово — создавать ID на клиенте. Более того, ни разу этого не видел нигде. Для этого есть служба
bnk>В смысле, чтобы создать новый объект, ты делаешь запрос к этой службе что ли?
bnk>Тормоза же, плюс поддержка этой никому не нужной службы.
Ну, конечно. Никаких тормозов нет (это делается при сохранении, всё равно же сохранять).

bnk>>>Разделение базы на несколько, допустим по регионам, или просто создание архива по датам (отдельная база).
В>>В век микросервисов вообще непонятно, зачем это может кому-нибудь потребоваться. Базы же маленькие. Если таки у тебя огромная база по каким-то причинам, то для этого есть другие архитектурные решения.

bnk>Так я еще эти микросервисы толком разглядеть не успел, а они вроде уже всё

Автор: BlackEric
Дата: 22.11.21

?
Я сильно в этом сомневаюсь-))) Уже накопилась изрядная индусская масса, которая в принципе иначе не работает. Если ты говоришь, что у MS есть минусы, у них сразу грустнеют глаза.

bnk>>>Где они его возьмут, если его нет в базе?
В>>Понятно, что в базе он должен быть. Только как это связано с гуидами?

bnk>Не понял. Мы же и говорим про базу. Что он должен там быть. Гуид.
Тогда уточни проблему.

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

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

Лично знаю проект, где упёрлись в размер int32 для ключа. Срочно переделывали на int64.

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

B>>> Я вот вообще не уверен, что это здорово — создавать ID на клиенте. Более того, ни разу этого не видел нигде. Для этого есть служба
bnk>В смысле, чтобы создать новый объект, ты делаешь запрос к этой службе что ли?
bnk>Тормоза же, плюс поддержка этой никому не нужной службы.

Создаёшь новый объект, тебе возвращается его ID. Вроде все так делают. Зачем тебе нужен ID ещё до того, как объект был создан?

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

vsb>Создаёшь новый объект, тебе возвращается его ID. Вроде все так делают. Зачем тебе нужен ID ещё до того, как объект был создан?

Например, если на клиенте уже есть собственная модель со связями.
Работа оффлайн например, и сохранение данных в localstorage или indexeddb.

Хотя этот случай тоже в какой-то степени синхронизация. Так что можно наверное обобщить и сказать,
что нужда в гуидах появляется, когда появляется больше одной "базы" (или другого хранилища объектов).

В случае веб-приложения, такой "базой" может быть любой браузер пользователя по сути.

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

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

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

MD>Лично знаю проект, где упёрлись в размер int32 для ключа. Срочно переделывали на int64.

Да, например для логов int32 может не хватать, но тут всё зависит от того, как часто в него писать, пока у меня имеется единственный случай, где стабильно пишется около 1.5К записей в секунду, т.е. в данном случае будет израсходован за месяц.
Зато вполне хватает для таких обыденных вещей как идентификатор товара (если конечно не глобальный уровень типа eBay/AliExpress/Amazon ...), новостной статьи, документа в корпоративной системе, или сообщения на этом форуме.

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

vsb>>Создаёшь новый объект, тебе возвращается его ID. Вроде все так делают. Зачем тебе нужен ID ещё до того, как объект был создан?

bnk>Например, если на клиенте уже есть собственная модель со связями.
bnk>Работа оффлайн например, и сохранение данных в localstorage или indexeddb.

bnk>Хотя этот случай тоже в какой-то степени синхронизация. Так что можно наверное обобщить и сказать,
bnk>что нужда в гуидах появляется, когда появляется больше одной "базы" (или другого хранилища объектов).

bnk>В случае веб-приложения, такой "базой" может быть любой браузер пользователя по сути.

Конечно uuid упрощает синхронизацию баз, но этот случай типичным назвать явно нельзя.

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

AB>Для больших баз уже никаких int быть не должно.

Т.е. для миллиарда записей перестроение индекса для каждой вставки это самое оно?

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

IT> AB>Для больших баз уже никаких int быть не должно.
IT> Т.е. для миллиарда записей перестроение индекса для каждой вставки это самое оно?

Уточни пожалуйста что именно ты имеешь ввиду? Если ты про вставку в середину индекса, то я ранее дал ответ на этот вопрос — uuid должен монотонно возрастать (таким свойством например обладает UUIDv1 после перестановки байт местами, но ничто не мешает генерировать собственный uuid-like идентификатор длиной 128 и более бит). В реальной практике, когда есть множество независимых генераторов, мы можем с высокой вероятностью гарантировать, что в худшем случае будет перестраиваться только хвост индекса, что существенно менее затратно.

Впрочем, есть базы относительно толерантные к вставке в середину индекса при наличии достаточного аппаратного обеспечения (из публично доступных HBase например).

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

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

Эм, ну так в базу никогда напрямую и не пускают, а только через какое-нибудь api. Но как это поможет, если на выходе этого api что-то в стиле:

{
  "id": "123456",
  "value": "Hello World!"
}

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

В> bnk>Тормоза же, плюс поддержка этой никому не нужной службы.
В> Ну, конечно. Никаких тормозов нет (это делается при сохранении, всё равно же сохранять).

Если ты в фоне не подкачиваешь id-шники в пул локально с достаточной скоростью, а ходишь каждый раз в службу генерации последовательности, то есть "тормоза" минимум в RTT (такого счастья на практике конечно никогда не бывает). Дополнительно ты ожидаешь блокировок от других клиентов, периодически ловишь tcp retransmit-ы и прочие прелести работы сети включая ее отказы. И это мы еще не затрагиваем организацию самой службы генерации, ее отказоустойчивость, балансировку нагрузки, синхронизацию между нодами и т.д.

Служба подобного типа имеет смысл для распределенных транзакций/блокировок (ну просто потому что по другому ты не сделаешь), а вот при генерации id куда как проще и надежнее иметь локальный независимый генератор.

Здравствуйте, Ватакуси, Вы писали:
В>Ну, конечно. Никаких тормозов нет (это делается при сохранении, всё равно же сохранять).
А можно попо дробнее с этого места?
Как именно вы предлагаете получать ID при сохранении? Да ещё и так, чтобы не было тормозов?
Я знаю три способа, из них два — неправильные:
1. Берём и делаем POST /mytransactions/<CRLFCRLF>{"from":112312312, "to": 8908094654, "amount": 500.00}
При получении таймаута, 10060, или 50x мы начинаем дорогостоящую процедуру восстановления синхронности клиента и сервера
2. Берём и делаем POST /mytransactions/<CRLF>X-Request-ID: 9b74165a-b248-4e99-9d57-a8066878e7ca<CRLFCRLF>{"from":112312312, "to": 8908094654, "amount": 500.00}.
Тут мы хотя бы имеем возможность корректно обработать фейлы. Но эта обработка достаточно неудобна: нам надо иметь какой-то временный ID нашей транзакции (а точнее — реквеста по её созданию), который потом заменять на "настоящий" ID, который вернёт сервис.
3. Ну, и нормальный способ — берём и делаем PUT /mytransactions/9b74165a-b248-4e99-9d57-a8066878e7ca<CRLFCRLF>{"from":112312312, "to": 8908094654, "amount": 500.00}
ID транзакции известен в момент её порождения, он ничем не будет заменяться, ждать сервера для его получения не надо.

Здравствуйте, vsb, Вы писали:
vsb>Создаёшь новый объект, тебе возвращается его ID. Вроде все так делают. Зачем тебе нужен ID ещё до того, как объект был создан?
А если при создании ты получил не ID, а 502 Gateway timeout? Каким образом узнать, был ли объект создан, или ещё нет?

Здравствуйте, Anton Batenev, Вы писали:
AB>Впрочем, есть базы относительно толерантные к вставке в середину индекса при наличии достаточного аппаратного обеспечения (из публично доступных HBase например).
Брр. А какие базы нетолерантны к вставке в середину индекса?

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

vsb>>Создаёшь новый объект, тебе возвращается его ID. Вроде все так делают. Зачем тебе нужен ID ещё до того, как объект был создан?
S>А если при создании ты получил не ID, а 502 Gateway timeout? Каким образом узнать, был ли объект создан, или ещё нет?

Никаким, показываешь пользователю, что произошла ошибка, а дальше пусть сам разбирается.

Здравствуйте, vsb, Вы писали:
vsb>Никаким, показываешь пользователю, что произошла ошибка, а дальше пусть сам разбирается.
Офигенно придумано. А если пользователя нет — это у нас фоновый процесс? Ну, там, мы получили подтверждение поставки, и теперь надо деньги перевести поставщику?

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

vsb>>Никаким, показываешь пользователю, что произошла ошибка, а дальше пусть сам разбирается.
S>Офигенно придумано. А если пользователя нет — это у нас фоновый процесс? Ну, там, мы получили подтверждение поставки, и теперь надо деньги перевести поставщику?

Это ты пытаешься какой-то вариант выдумать, где без UUID никак? Ну можно такой вариант выдумать, и что? Обычно пользователь есть и так или иначе он сможешь разрулить такую проблему самостоятельно. А ты что будешь делать, если получишь 502? Ну попробуешь перевести ещё раз и опять получишь 502. И десять раз получишь 502, и сто раз. Всё равно в итоге всё упадёт (ну или будет гадить в логи без перерыва) и всё.

Поэтому ответ на твой вопрос — зафиксировать ошибку в логах и более ничего не предпринимать. Поставщик позвонит, пожалуется и разберёмся. А если такое случается два раза, значит будет какой-нибудь алёрт по этому логу. Ну или таки пошевелимся и исправим причину, по которой там этот 502 возникает. Как-то так.

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

vsb>Это ты пытаешься какой-то вариант выдумать, где без UUID никак?
Нет, просто удивлён тем, что в 2021 году есть люди, незнакомые с REST.

vsb>Ну можно такой вариант выдумать, и что? Обычно пользователь есть и так или иначе он сможешь разрулить такую проблему самостоятельно. А ты что будешь делать, если получишь 502? Ну попробуешь перевести ещё раз и опять получишь 502. И десять раз получишь 502, и сто раз. Всё равно в итоге всё упадёт (ну или будет гадить в логи без перерыва) и всё.
Вовсе даже не всё равно. В вашем варианте сто 502 могут означать 100 повторов перевода денег, или 100 повторных заказов в магазине.

vsb>Поэтому ответ на твой вопрос — зафиксировать ошибку в логах и более ничего не предпринимать. Поставщик позвонит, пожалуется и разберёмся. А если такое случается два раза, значит будет какой-нибудь алёрт по этому логу. Ну или таки пошевелимся и исправим причину, по которой там этот 502 возникает. Как-то так.
Обычно 502 исправляется очень быстро, потому что его причиной является перезапуск одного из серверов в цепочке. Очень немногие приложения могут себе позволить в такой ситуации просто лечь и требовать ручного перезапуска.
Да ещё и с ручной коррекцией данных — потому, что встроенного способа восстановить синхронность нет, и надо руками проверять, была ли выполнена операция, и на клиентской стороне править базу соответствующим образом.

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

S> Брр. А какие базы нетолерантны к вставке в середину индекса?

Например MySQL будет плохо на интенсивной вставке в рандомные места pk при большом размере таблицы. Другим "традиционным" БД скорее всего так же будет в разной степени нехорошо (чудес не бывает), но MySQL — это просто хрестоматийный пример грабли, на которую "новички" наступают с завидной регулярностью.

Здравствуйте, Anton Batenev, Вы писали:
AB>Например MySQL будет плохо на интенсивной вставке в рандомные места pk при большом размере таблицы. Другим "традиционным" БД скорее всего так же будет в разной степени нехорошо (чудес не бывает), но MySQL — это просто хрестоматийный пример грабли, на которую "новички" наступают с завидной регулярностью.
Мне очень интересно, как это может работать.
Что за индексы использует MySQL?
B-Tree, Hash, и Bitmap индексам совершенно всё равно, в каком порядке идёт вставка. Точнее, для некоторых из них могут быть интересные эффекты, связанные с блокировками (если они используются), но они как бы имеют второй порядок малости по сравнению с основным членом разложения асимптотики, да ещё и работают "в другую сторону", ускоряя вставку при равномерном её разбросе по диапазону ключа.

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

S> AB>Например MySQL будет плохо на интенсивной вставке в рандомные места pk при большом размере таблицы. Другим "традиционным" БД скорее всего так же будет в разной степени нехорошо (чудес не бывает), но MySQL — это просто хрестоматийный пример грабли, на которую "новички" наступают с завидной регулярностью.
S> Мне очень интересно, как это может работать.
S> Что за индексы использует MySQL?

Как-то так: innodb-page-merging-and-page-splitting.

Здравствуйте, Anton Batenev, Вы писали:
AB>Как-то так: innodb-page-merging-and-page-splitting.
Ну, там начато за здравие, а закончено за упокой.
В том смысле, что сначала идёт неплохой рассказ про B-деревья, и их реализацию в MySQL.
А вот в разделе MyPrimaryKey начинается булшит.
То есть сняты корректно, но объяснение причин явно бредовое. Вот эта вот фраза не имеет ничего общего с действительностью:

while the semi-random nature of the UUID will cause a significant “sparse” page distribution (causing a higher number of pages and related split operations).

Автор плохо учил математику, и не понимает, что коэффициент полноты страниц в B-дереве слабо связан с распределением вставки.
Более того, вставка в конец гарантирует fill-factor в 50%
Разница в производительности, которую наблюдает автор, связана с размером ключа, а не со случайностью порядка.
В MYSQL UUID хранится как строка, и занимает 36 байт. Естественно, индекс по 36-байтовому ключу потребует больше страниц, чем индекс по 4-байтовому ключу.

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

S> Разница в производительности, которую наблюдает автор, связана с размером ключа, а не со случайностью порядка.

Размер ключа конечно влияет, но на больших табличках его влияние незначительно за счет размера связанных данных. Ты можешь провести подобный же эксперимент с random uint64 — результат будет плюс-минус одинаковый (в сравнении со вставкой в хвост).

Если интересно, то можно почитать еще вот это: store-uuid-optimized-way. А вообще подобных исследований и докладов на всяких HighLoad-подобных конференциях в то время было достаточно много, если покопаться.

S> Более того, вставка в конец гарантирует fill-factor в 50%

IRL заполнение будет близко к 100% — так же легко подтверждается натурным экспериментом.

В>>Ну, конечно. Никаких тормозов нет (это делается при сохранении, всё равно же сохранять).
S>А можно попо дробнее с этого места?
S>Как именно вы предлагаете получать ID при сохранении? Да ещё и так, чтобы не было тормозов?
S>Я знаю три способа, из них два — неправильные:
S>1. Берём и делаем POST /mytransactions/<CRLFCRLF>{"from":112312312, "to": 8908094654, "amount": 500.00}
S>При получении таймаута, 10060, или 50x мы начинаем дорогостоящую процедуру восстановления синхронности клиента и сервера
S>2. Берём и делаем POST /mytransactions/<CRLF>X-Request-ID: 9b74165a-b248-4e99-9d57-a8066878e7ca<CRLFCRLF>{"from":112312312, "to": 8908094654, "amount": 500.00}.
S>Тут мы хотя бы имеем возможность корректно обработать фейлы. Но эта обработка достаточно неудобна: нам надо иметь какой-то временный ID нашей транзакции (а точнее — реквеста по её созданию), который потом заменять на "настоящий" ID, который вернёт сервис.
S>3. Ну, и нормальный способ — берём и делаем PUT /mytransactions/9b74165a-b248-4e99-9d57-a8066878e7ca<CRLFCRLF>{"from":112312312, "to": 8908094654, "amount": 500.00}
S>ID транзакции известен в момент её порождения, он ничем не будет заменяться, ждать сервера для его получения не надо.

Я не уверен, что мы говорим об одном и том же.
Твой клиент создал НЕЧТО. Но без ID. Далее он хочет сохранить это нечто. В этот момент ему и присваивается ID (который может быть возвращён вместе с ответом). Вернуться же может и многое другое (вычислимые поля, временные метки и т.п.). Их же никто на клиенте не создаёт, так?
Зачем создавать заранее ID, если объект (или запись) всё равно никуда ещё не сохранён?

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

В> Я не уверен, что мы говорим об одном и том же.
В> Твой клиент создал НЕЧТО. Но без ID. Далее он хочет сохранить это нечто. В этот момент ему и присваивается ID (который может быть возвращён вместе с ответом). Вернуться же может и многое другое (вычислимые поля, временные метки и т.п.). Их же никто на клиенте не создаёт, так?
В> Зачем создавать заранее ID, если объект (или запись) всё равно никуда ещё не сохранён?
Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?

Более того... Клиент может создать пачку НЕЧТ и послать на сохранение. Или продолжать создавать новые НЕЧТЫ пока сервер сохраняет предыдущие.

В>> Я не уверен, что мы говорим об одном и том же.
В>> Твой клиент создал НЕЧТО. Но без ID. Далее он хочет сохранить это нечто. В этот момент ему и присваивается ID (который может быть возвращён вместе с ответом). Вернуться же может и многое другое (вычислимые поля, временные метки и т.п.). Их же никто на клиенте не создаёт, так?
В>> Зачем создавать заранее ID, если объект (или запись) всё равно никуда ещё не сохранён?
·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
Повторить. Если сохранилось, то 201 и ответ. В чём сложность?

·>Более того... Клиент может создать пачку НЕЧТ и послать на сохранение. Или продолжать создавать новые НЕЧТЫ пока сервер сохраняет предыдущие.
Это что-то меняет?

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

В>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
В>Повторить. Если сохранилось, то 201 и ответ. В чём сложность?
Как сервер отличит повтор от нового НЕЧТО?

В>·>Более того... Клиент может создать пачку НЕЧТ и послать на сохранение. Или продолжать создавать новые НЕЧТЫ пока сервер сохраняет предыдущие.
В>Это что-то меняет?
Тем, что НЕЧТЫ надо между собой как-то идентифицировать ещё до сохранения на сервере.

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

В>>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
В>>Повторить. Если сохранилось, то 201 и ответ. В чём сложность?
·>Как сервер отличит повтор от нового НЕЧТО?

Если это нечто настолько важное, то для него можно использовать натуральный ключ. В этом случае проверка наличия натурального ключа в БД покажет, сохранилось оно или нет.

В>>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
В>>Повторить. Если сохранилось, то 201 и ответ. В чём сложность?
·>Как сервер отличит повтор от нового НЕЧТО?
Куча способов. От целостности ДБ (уникальные ключи и т.п.) до проверки модели ДБ на сервере.
Полагаться на ID с клиента для подобного — это мягко говоря — так себе идея.

В>>·>Более того... Клиент может создать пачку НЕЧТ и послать на сохранение. Или продолжать создавать новые НЕЧТЫ пока сервер сохраняет предыдущие.
В>>Это что-то меняет?
·>Тем, что НЕЧТЫ надо между собой как-то идентифицировать ещё до сохранения на сервере.
Они же либо пачкой отправляются, либо отдельными запросами. В любом случае ты получишь ответ соответсвующий каждому из них. Даже, если это асинхронно выполнять.

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

В>>>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
В>>>Повторить. Если сохранилось, то 201 и ответ. В чём сложность?
G>·>Как сервер отличит повтор от нового НЕЧТО?
G>Если это нечто настолько важное, то для него можно использовать натуральный ключ. В этом случае проверка наличия натурального ключа в БД покажет, сохранилось оно или нет.
Ок. Давай конкретный пример, пусть нечто заказ: "Принесите мне чашку кофе". Как сервер отличит повтор заказа, т.к. клиент не услышал ответа и повтор заказа, т.к. клиент хочет ещё одну чашечку? В этом случае ключом натурально становится уникальный идентификатор заказа. Который проще всего сгенерить на клиенте.

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

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

А long?

Упдате: увидел ответ выше. Вопрос закрыт.

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

В>>>>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
В>>>>Повторить. Если сохранилось, то 201 и ответ. В чём сложность?
G>>·>Как сервер отличит повтор от нового НЕЧТО?
G>>Если это нечто настолько важное, то для него можно использовать натуральный ключ. В этом случае проверка наличия натурального ключа в БД покажет, сохранилось оно или нет.
·>Ок. Давай конкретный пример, пусть нечто заказ: "Принесите мне чашку кофе". Как сервер отличит повтор заказа, т.к. клиент не услышал ответа и повтор заказа, т.к. клиент хочет ещё одну чашечку? В этом случае ключом натурально становится уникальный идентификатор заказа. Который проще всего сгенерить на клиенте.

Если ключ генерится случайно, то имхо есть вероятность коллизии. Я понимаю, что эта вероятность мизерна, но "осадочек остается", я до сих пор не могу привыкнуть к гуидам, не покидает ощущение что это плохая технология и когда-нибудь она выстрелит по человечеству такой неприятной коллизией, таким "черным лебедем", что мало не покажется. Не лучше ли в таком случае генерить уникальный ключ с привязкой к названию кафешки (или к её гео-координатам) и ко времени заказа? Например:
STARBUCKS-4756-07-12-2021-16-22-56-045-UTC
вместо
2062b11c-4ecb-42aa-be35-798203a758f9

В этом случае такой натуральный ключ имеет минимальные шансы коллизии, т.к. в одну и ту же миллисекунду маловероятен заказ нескольких кружек кофе в одной кафешке. Но даже если и вероятен, например если касс несколько, то в ключ можно добавлять и id кассы:
STARBUCKS-4756-07-12-2021-16-22-56-045-UTC-545663

С таким id и работать приятнее, нет того неприятного ощущения что он "чуховый" и "коллизийный", чем с каким-то непонятным гуидом, который сгенерён по непонятному алгоритму.

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

В>>>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
В>>>Повторить. Если сохранилось, то 201 и ответ. В чём сложность?
В>·>Как сервер отличит повтор от нового НЕЧТО?
В>Куча способов.
Опиши конкретно, с подробностями хотя бы один из них.

В>От целостности ДБ (уникальные ключи и т.п.)
Эээ.. Т.е. чтобы у нас был уникальный ключ нам нужно иметь уникальный ключ?..

В>до проверки модели ДБ на сервере.
Это как? Модели чего? Проблема в рассинхронизации между клиентом и сервером. Сервер не знает что у клиента, клиент не знает что у сервера.

В>Полагаться на ID с клиента для подобного — это мягко говоря — так себе идея.
Это не то что идея, это неизбежный вариант.

В>>>·>Более того... Клиент может создать пачку НЕЧТ и послать на сохранение. Или продолжать создавать новые НЕЧТЫ пока сервер сохраняет предыдущие.
В>>>Это что-то меняет?
В>·>Тем, что НЕЧТЫ надо между собой как-то идентифицировать ещё до сохранения на сервере.
В>Они же либо пачкой отправляются, либо отдельными запросами.
Т.е. ты должен неявно отправить N штук и потом ждать N назад, сопоставляя по очередности. Вариант, конечно, но опять всё сломается при сетевых ошибках, да и не очень очевидно в чём преимущества.

В>В любом случае ты получишь ответ соответсвующий каждому из них. Даже, если это асинхронно выполнять.
Асинхронно вообще бардак начаться может, если, скажем, сервер работает в нескольких экземплярах и в итоге запросы могут обрабатываться не по порядку.

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

G>·>Ок. Давай конкретный пример, пусть нечто заказ: "Принесите мне чашку кофе". Как сервер отличит повтор заказа, т.к. клиент не услышал ответа и повтор заказа, т.к. клиент хочет ещё одну чашечку? В этом случае ключом натурально становится уникальный идентификатор заказа. Который проще всего сгенерить на клиенте.
G>Если ключ генерится случайно, то имхо есть вероятность коллизии. Я понимаю, что эта вероятность мизерна, но "осадочек остается", я до сих пор не могу привыкнуть к гуидам, не покидает ощущение что это плохая технология и когда-нибудь она выстрелит по человечеству такой неприятной коллизией, таким "черным лебедем", что мало не покажется.
This number is equivalent to generating 1 billion UUIDs per second for about 85 years.
https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions

А если сделать, чтобы данные устаревали (т.е. удалять очень старые заказы), то вообще всё невероятно.

G>Не лучше ли в таком случае генерить уникальный ключ с привязкой к названию кафешки (или к её гео-координатам) и ко времени заказа?
Это аналогично UUID v1 или v2.

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

В>Я не уверен, что мы говорим об одном и том же.
Об одном, об одном.
В>Твой клиент создал НЕЧТО. Но без ID. Далее он хочет сохранить это нечто. В этот момент ему и присваивается ID (который может быть возвращён вместе с ответом). Вернуться же может и многое другое (вычислимые поля, временные метки и т.п.). Их же никто на клиенте не создаёт, так?
В>Зачем создавать заранее ID, если объект (или запись) всё равно никуда ещё не сохранён?
Повторю вопрос: что будет в вашей схеме, если клиент отправил объект на сохранение, но подтвержения (и ID вместе с ним) не получил?
Как он отличит ситуацию "запрос потерян на пути к серверу" от ситуации "ответ потерян на пути от сервера"?

В>>>>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
В>>>>Повторить. Если сохранилось, то 201 и ответ. В чём сложность?
В>>·>Как сервер отличит повтор от нового НЕЧТО?
В>>Куча способов.
·>Опиши конкретно, с подробностями хотя бы один из них.
Хорошо.

В>>От целостности ДБ (уникальные ключи и т.п.)
·>Эээ.. Т.е. чтобы у нас был уникальный ключ нам нужно иметь уникальный ключ?..
Нет, у тебя всегда (ну, почти) есть уникальные поля (или их сочетания).
Нельзя, например, создать документ с ровно таким же названием как уже существующий (уникальность по имени) или в пределах определённого раздела (уникальность по двум или более полям).

В>>до проверки модели ДБ на сервере.
·>Это как? Модели чего? Проблема в рассинхронизации между клиентом и сервером. Сервер не знает что у клиента, клиент не знает что у сервера.
Ну, спрашиваещь базу, кэш или что-нибудь ещё есть у меня такой объект с такими полями или нет.

В>>Полагаться на ID с клиента для подобного — это мягко говоря — так себе идея.
·>Это не то что идея, это неизбежный вариант.
Ну, прислал ты два разных ID, но объекты 100% одинаковые. У тебя база или служба ВСЁ РАВНО должны это обработать. Тогда зачем платить больше?

В>>>>·>Более того... Клиент может создать пачку НЕЧТ и послать на сохранение. Или продолжать создавать новые НЕЧТЫ пока сервер сохраняет предыдущие.
В>>>>Это что-то меняет?
В>>·>Тем, что НЕЧТЫ надо между собой как-то идентифицировать ещё до сохранения на сервере.
В>>Они же либо пачкой отправляются, либо отдельными запросами.
·>Т.е. ты должен неявно отправить N штук и потом ждать N назад, сопоставляя по очередности. Вариант, конечно, но опять всё сломается при сетевых ошибках, да и не очень очевидно в чём преимущества.
Не знаю про ваших клиентов, но у меня за такое отвечает библиотека, которая выполняет запросы. Или среда исполнения.

В>>В любом случае ты получишь ответ соответсвующий каждому из них. Даже, если это асинхронно выполнять.
·>Асинхронно вообще бардак начаться может, если, скажем, сервер работает в нескольких экземплярах и в итоге запросы могут обрабатываться не по порядку.
Ну и что? Вернуться же они куда надо и кому надо.

В>>Твой клиент создал НЕЧТО. Но без ID. Далее он хочет сохранить это нечто. В этот момент ему и присваивается ID (который может быть возвращён вместе с ответом). Вернуться же может и многое другое (вычислимые поля, временные метки и т.п.). Их же никто на клиенте не создаёт, так?
В>>Зачем создавать заранее ID, если объект (или запись) всё равно никуда ещё не сохранён?
S>Повторю вопрос: что будет в вашей схеме, если клиент отправил объект на сохранение, но подтвержения (и ID вместе с ним) не получил?
S>Как он отличит ситуацию "запрос потерян на пути к серверу" от ситуации "ответ потерян на пути от сервера"?
Так если нет соединения в принципе, то никак.
Если оно есть, то повтор. Далее через 200, 201 или 409 можно управлять "пониманием".
Но, к слову, в современных клиентах вообще никто не парится. Не прошло, ошибку вернул и всё. Пусть "кто-нить другой" пытается повторить.

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

vsb>>>Создаёшь новый объект, тебе возвращается его ID. Вроде все так делают. Зачем тебе нужен ID ещё до того, как объект был создан?
S>>А если при создании ты получил не ID, а 502 Gateway timeout? Каким образом узнать, был ли объект создан, или ещё нет?

vsb>Никаким, показываешь пользователю, что произошла ошибка, а дальше пусть сам разбирается.

Вот все мне тут смайлики ставят, можно подумать, я не вижу этих страничек с "ой произошла ошибка" на этих ваших крупных сайтах. У меня банковское приложение "произошла ошибка, перезагрузите страницу" чуть ли не каждый день показывает, вместо того, чтобы какие-то там повторы делать. Несколько лет назад пейпал два раза с карты списал, когда я нажал "назад" и ещё раз сабмит нажал, т.к. он слишком долго думал. И это я про финансовые сервисы сейчас говорю. А обычные сайты сыплют ошибками только так. А если не сыплют, значит тупо игнорят. Вот щас захожу на amazon.com главную страницу и в логах вижу 404 https://www.amazon.com/gp/product/sessionCacheUpdateHandler.html. То бишь им даже лень функциональный тест написать, который главную страницу открывает и проверяет, что там ошибок нет. А вы мне расписываете про какие-то идемпотентные PUT-ы.

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

S>Повторю вопрос: что будет в вашей схеме, если клиент отправил объект на сохранение, но подтвержения (и ID вместе с ним) не получил?
S>Как он отличит ситуацию "запрос потерян на пути к серверу" от ситуации "ответ потерян на пути от сервера"?

Меня не оставляет чувство, что некоторые участники дискуссии не знакомы с делопроизводством с его "входящими" и "исходящими" номерами обращений.

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

В>>>От целостности ДБ (уникальные ключи и т.п.)
В>·>Эээ.. Т.е. чтобы у нас был уникальный ключ нам нужно иметь уникальный ключ?..
В>Нет, у тебя всегда (ну, почти) есть уникальные поля (или их сочетания).
Это называется натуральный ключ. И это таки ключ генерируемый на клиенте. Да, если бизнес-сущность имеет натуральный ключ, то можно использовать его. Если такого ключа нет, то придётся использовать гуид — суррогатный ключ.

При этом у тебя размазывается логика между клиентом и сервером. Клиент должен точно знать что сервер считает натуральным ключом, чтобы восстанавливаться после сбоя. В случае с гуидом — поля будут просто поля. И сервер может отвечать на попытку сохранения документа — "успех" или "дубликат", контролируя логику проверки дубликатов. Называется разделение обязанностей: идентификатор идентифицирует документ для синхронизации между клиентом и сервером, а значения полей, в т.ч. их уникальность в определённом разделе, етс — это относится к валидации данных документа.

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

В>>>до проверки модели ДБ на сервере.
В>·>Это как? Модели чего? Проблема в рассинхронизации между клиентом и сервером. Сервер не знает что у клиента, клиент не знает что у сервера.
В>Ну, спрашиваещь базу, кэш или что-нибудь ещё есть у меня такой объект с такими полями или нет.
Т.е. запрос по какому-то ключу.

В>>>Полагаться на ID с клиента для подобного — это мягко говоря — так себе идея.
В>·>Это не то что идея, это неизбежный вариант.
В>Ну, прислал ты два разных ID, но объекты 100% одинаковые. У тебя база или служба ВСЁ РАВНО должны это обработать. Тогда зачем платить больше?
Да — и мне выдали две мои заказанные одинаковые чашки кофе. Не понял где платится больше.

В>>>·>Тем, что НЕЧТЫ надо между собой как-то идентифицировать ещё до сохранения на сервере.
В>>>Они же либо пачкой отправляются, либо отдельными запросами.
В>·>Т.е. ты должен неявно отправить N штук и потом ждать N назад, сопоставляя по очередности. Вариант, конечно, но опять всё сломается при сетевых ошибках, да и не очень очевидно в чём преимущества.
В>Не знаю про ваших клиентов, но у меня за такое отвечает библиотека, которая выполняет запросы. Или среда исполнения.
Т.е. запросы неявно идентифицируются библиотекой или средой исполнения. Та же ж только в профиль.

В>>>В любом случае ты получишь ответ соответсвующий каждому из них. Даже, если это асинхронно выполнять.
В>·>Асинхронно вообще бардак начаться может, если, скажем, сервер работает в нескольких экземплярах и в итоге запросы могут обрабатываться не по порядку.
В>Ну и что? Вернуться же они куда надо и кому надо.
Не волшебным же способом, а используя некую идентификацию.

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

В>>>Твой клиент создал НЕЧТО. Но без ID. Далее он хочет сохранить это нечто. В этот момент ему и присваивается ID (который может быть возвращён вместе с ответом). Вернуться же может и многое другое (вычислимые поля, временные метки и т.п.). Их же никто на клиенте не создаёт, так?
В>>>Зачем создавать заранее ID, если объект (или запись) всё равно никуда ещё не сохранён?
S>>Повторю вопрос: что будет в вашей схеме, если клиент отправил объект на сохранение, но подтвержения (и ID вместе с ним) не получил?
S>>Как он отличит ситуацию "запрос потерян на пути к серверу" от ситуации "ответ потерян на пути от сервера"?
В>Так если нет соединения в принципе, то никак.
Нет никакого "в принципе". Канал, которым мы пользуемся, состоит из пакетов. Это означает, что соединение может быть потеряно в любой момент — более того, бывает так, что пакеты "туда" успешно доходят, а пакеты "обратно" — нет.
В>Если оно есть, то повтор. Далее через 200, 201 или 409 можно управлять "пониманием".
Ну, и как вы собрались управлять этим пониманием через 200, 201, 409?
Для начала серверу нужно как-то научиться отличать запрос клиента "сохрани ещё один заказ" от "я не понял, ты вот этот заказ уже сохранил?".
В>Но, к слову, в современных клиентах вообще никто не парится. Не прошло, ошибку вернул и всё. Пусть "кто-нить другой" пытается повторить.
Далеко не во всех клиентах. Сколько вы видели веб-магазинов, которые при повторном нажатии на кнопку "оформить" оформляют дубликаты заказов?
В начале 2000х так себя вёл каждый первый магазин. Некоторые даже деньги неоднократно списывали за один и тот же товар.

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

vsb> ... А вы мне расписываете про какие-то идемпотентные PUT-ы.

Теоретики, Сэр, с проявлениями RESTFul-синдрома головного мозга.

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

Пример:
клиент получает новый идентификатор запроса, может сам его сгенерить (если GUID), либо получить с сервера отдельным вызовом.
Это может быть и последовательный счетчик, но это противоречит вопросам безопастности, ибо очень просто подменить.

Далее клиент с этим ключем пытается чего-то сделать, если при выполнении запроса произошла ошибка, то клиент сможет повторно опрашивать по этому ключу состояние на сервере, т.к. на сервере операция могла быть выполнена успешно, но во время отправки/приема ответа произошло что-то нехорошее.

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

G>Если ключ генерится случайно, то имхо есть вероятность коллизии. Я понимаю, что эта вероятность мизерна, но "осадочек остается", я до сих пор не могу привыкнуть к гуидам, не покидает ощущение что это плохая технология и когда-нибудь она выстрелит по человечеству такой неприятной коллизией, таким "черным лебедем", что мало не покажется.
Эмм.
G>Не лучше ли в таком случае генерить уникальный ключ с привязкой к названию кафешки (или к её гео-координатам) и ко времени заказа? Например:
G>STARBUCKS-4756-07-12-2021-16-22-56-045-UTC
G>вместо
G>2062b11c-4ecb-42aa-be35-798203a758f9
Вот вы сейчас пытаетесь изобрести GUID, плохо понимая, как работает существующий GUID. Вы уверены, что ваша разработка будет не хуже, чем оригинал?
G>С таким id и работать приятнее, нет того неприятного ощущения что он "чуховый" и "коллизийный", чем с каким-то непонятным гуидом, который сгенерён по непонятному алгоритму.
Лично у меня, конечно же, есть именно неприятное ощущение того, что ваш ID "чуховый" и "коллизийный". Потому, что алгоритмы генерации GUID я знаю, и понимаю предположения, лежащие в их основе. Знаю, чем v2 отличается от v4.
А что там себе думали вы, и какие ситуации забыли предусмотреть — хз.

На всякий случай подчеркну, что я не считаю GUID идеалом, который нечем заменить. Но когда вы берётесь изобретать свой собственный механизм распределённой генерации уникальных идентификаторов, то важна мотивация.
Мотивация "я не понимаю, как работает GUID, поэтому я придумаю свой" — плохая. Хорошая мотивация — "я понимаю, как работает GUID, и меня не устраивают такие-то и такие-то аспекты. Поэтому я придумаю свой алгоритм, который будет отличаться именно в этих аспектах нужным мне образом".

Здравствуйте, vsb, Вы писали:
vsb>Вот все мне тут смайлики ставят, можно подумать, я не вижу этих страничек с "ой произошла ошибка" на этих ваших крупных сайтах. У меня банковское приложение "произошла ошибка, перезагрузите страницу" чуть ли не каждый день показывает, вместо того, чтобы какие-то там повторы делать. Несколько лет назад пейпал два раза с карты списал, когда я нажал "назад" и ещё раз сабмит нажал, т.к. он слишком долго думал. И это я про финансовые сервисы сейчас говорю. А обычные сайты сыплют ошибками только так. А если не сыплют, значит тупо игнорят. Вот щас захожу на amazon.com главную страницу и в логах вижу 404 https://www.amazon.com/gp/product/sessionCacheUpdateHandler.html. То бишь им даже лень функциональный тест написать, который главную страницу открывает и проверяет, что там ошибок нет. А вы мне расписываете про какие-то идемпотентные PUT-ы.
Мир не исчерпывается фронт-ендом, в котором есть кому показать ошибку, да ещё и в одноразовой транзакции.
Когда вы пользуетесь банковским приложением, помимо вот этого вот обмена http-запросами между клиентом и сервером, есть ещё огромная махина процессинга транзакций. И в ней некого попросить "перезагрузите страницу".
Там повторы делаются автоматически, и работают очень надёжно. Вы не видите и следа тех сбоев, которые в реальности постоянно происходят во время сведения счетов между банками.

Поэтому вместо того, чтобы кивать на ошибки пейпала, вам стоит изучить способы корректного решения таких задач. Всё надо стараться делать как следует — чё попало у вас получится само.

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

S>На всякий случай подчеркну, что я не считаю GUID идеалом, который нечем заменить. Но когда вы берётесь изобретать свой собственный механизм распределённой генерации уникальных идентификаторов, то важна мотивация.
S>Мотивация "я не понимаю, как работает GUID, поэтому я придумаю свой" — плохая. Хорошая мотивация — "я понимаю, как работает GUID, и меня не устраивают такие-то и такие-то аспекты. Поэтому я придумаю свой алгоритм, который будет отличаться именно в этих аспектах нужным мне образом".

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

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


bnk>>Элементарный импорт-экспорт данных в каком-нибудь текстовом формате.
bnk>>Объекты в экспортируемом файле должны иметь (глобально) уникальный идентификатор, иначе будет каша.
В>Это почему ещё?

bnk>>Где они его возьмут, если его нет в базе?
В>Понятно, что в базе он должен быть. Только как это связано с гуидами?

Ну потому что хотя бы по REST все ресурсы должны быть уникальны и глобальны.

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

B>>>> Я вот вообще не уверен, что это здорово — создавать ID на клиенте. Более того, ни разу этого не видел нигде. Для этого есть служба
bnk>>В смысле, чтобы создать новый объект, ты делаешь запрос к этой службе что ли?
bnk>>Тормоза же, плюс поддержка этой никому не нужной службы.
vsb>Создаёшь новый объект, тебе возвращается его ID. Вроде все так делают. Зачем тебе нужен ID ещё до того, как объект был создан?

Для шардирования, как вариант

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

4>Если кратко, вариант когда идентификатор/ключ возвращается сервером после совершения транзакции/операции вполне распространён в тонких клиентах, вариант где идентификатор/ключ передаётся клиентом, распространен в более толстых клиентах (это может быть тоже веб, но с большей долей клиентского script-инга), чтобы организовать логику по опросу состояния выполнения операции.
Даже на этом сайте есть защита от повторной отправки сообщения.
Как я это вижу — сценарий зависит от толщины не клиента, а коры головного мозга у разработчиков. Фронт-енд зачастую доверяют ваять совсем уж беспомощным разработчикам, которые даже основ архитектуры не ведают. Ни о проблеме двух генералов, ни о Догадке Брюера они не слышали.
Если за фронт-енд садятся люди с минимальным опытом в архитектуре, получается то, что вы называете "тоже веб, но с большей долей клиентского script-инга". Хотя скриптинга там может быть ненамного больше, чем в "тонком клиенте", где всё рендерится через динамический DOM, порождаемый javascript (если не вообще напрямую через canvas). Просто взять и прикрутить https://stackoverflow.com/questions/105034/how-to-create-a-guid-uuid к странице очень дешево; дорого стоит знание того, что это вообще надо делать.

4>Далее клиент с этим ключем пытается чего-то сделать, если при выполнении запроса произошла ошибка, то клиент сможет повторно опрашивать по этому ключу состояние на сервере, т.к. на сервере операция могла быть выполнена успешно, но во время отправки/приема ответа произошло что-то нехорошее.
Даже если клиент не умеет в полноценную асинхронность (а это не так легко сделать — можно было наблюдать этапы решения подобной задачи, глядя на последовательные версии Microsoft Outlook в девяностых и двухтысячных), как минимум способность ещё раз послать тот же запрос ему может быть крайне полезна.

bnk>>>Элементарный импорт-экспорт данных в каком-нибудь текстовом формате.
bnk>>>Объекты в экспортируемом файле должны иметь (глобально) уникальный идентификатор, иначе будет каша.
S>В>Это почему ещё?
А иначе нет гарантии на не пересечение идентификаторов.

bnk>>>Где они его возьмут, если его нет в базе?
S>В>Понятно, что в базе он должен быть. Только как это связано с гуидами?

S>Ну потому что хотя бы по REST все ресурсы должны быть уникальны и глобальны.
Ты уверен? Точно?
Но даже если это предположить, то опять как это связано с гуидами?

В>>>>Зачем создавать заранее ID, если объект (или запись) всё равно никуда ещё не сохранён?
S>>>Повторю вопрос: что будет в вашей схеме, если клиент отправил объект на сохранение, но подтвержения (и ID вместе с ним) не получил?
S>>>Как он отличит ситуацию "запрос потерян на пути к серверу" от ситуации "ответ потерян на пути от сервера"?
В>>Так если нет соединения в принципе, то никак.
S>Нет никакого "в принципе". Канал, которым мы пользуемся, состоит из пакетов. Это означает, что соединение может быть потеряно в любой момент — более того, бывает так, что пакеты "туда" успешно доходят, а пакеты "обратно" — нет.
Соединение или есть или его нет. Пакеты/макеты, это не существенно. И даже если у тебя гуид, без соеденения ты ничего не сдеаешь.

В>>Если оно есть, то повтор. Далее через 200, 201 или 409 можно управлять "пониманием".
S>Ну, и как вы собрались управлять этим пониманием через 200, 201, 409?
Как угодно. Зависит от логики и требования. В чём именно сложности?

S>Для начала серверу нужно как-то научиться отличать запрос клиента "сохрани ещё один заказ" от "я не понял, ты вот этот заказ уже сохранил?".
В>>Но, к слову, в современных клиентах вообще никто не парится. Не прошло, ошибку вернул и всё. Пусть "кто-нить другой" пытается повторить.
S>Далеко не во всех клиентах. Сколько вы видели веб-магазинов, которые при повторном нажатии на кнопку "оформить" оформляют дубликаты заказов?
S>В начале 2000х так себя вёл каждый первый магазин. Некоторые даже деньги неоднократно списывали за один и тот же товар.
Речь же не идёт про те редкие случаи, когда нет возможности определить есть объект в базе или нет.

В>>>>От целостности ДБ (уникальные ключи и т.п.)
В>>·>Эээ.. Т.е. чтобы у нас был уникальный ключ нам нужно иметь уникальный ключ?..
В>>Нет, у тебя всегда (ну, почти) есть уникальные поля (или их сочетания).
·>Это называется натуральный ключ. И это таки ключ генерируемый на клиенте. Да, если бизнес-сущность имеет натуральный ключ, то можно использовать его. Если такого ключа нет, то придётся использовать гуид — суррогатный ключ.
Начал отлично, но закончил как всегда.
Суррогатный ключ нужен в редких случаях, с этим согласен?

·>При этом у тебя размазывается логика между клиентом и сервером. Клиент должен точно знать что сервер считает натуральным ключом, чтобы восстанавливаться после сбоя. В случае с гуидом — поля будут просто поля. И сервер может отвечать на попытку сохранения документа — "успех" или "дубликат", контролируя логику проверки дубликатов. Называется разделение обязанностей: идентификатор идентифицирует документ для синхронизации между клиентом и сервером, а значения полей, в т.ч. их уникальность в определённом разделе, етс — это относится к валидации данных документа.
Как же она размазывается, если это основа всех основ?
Повторюсь. Если даже ты шлёшь гуиды свои, то всё равно (за редким исключением) придётся делать логику на уникальность объекта. Это никуда не денется. Вообще никуда.

В>>>>до проверки модели ДБ на сервере.
В>>·>Это как? Модели чего? Проблема в рассинхронизации между клиентом и сервером. Сервер не знает что у клиента, клиент не знает что у сервера.
В>>Ну, спрашиваещь базу, кэш или что-нибудь ещё есть у меня такой объект с такими полями или нет.
·>Т.е. запрос по какому-то ключу.
По "натуральному".

В>>>>Полагаться на ID с клиента для подобного — это мягко говоря — так себе идея.
В>>·>Это не то что идея, это неизбежный вариант.
В>>Ну, прислал ты два разных ID, но объекты 100% одинаковые. У тебя база или служба ВСЁ РАВНО должны это обработать. Тогда зачем платить больше?
·>Да — и мне выдали две мои заказанные одинаковые чашки кофе. Не понял где платится больше.
Там, где у тебя не чашки. А например документы. С уникальными именами. Или возврат налогов (который только один в один финансовый год). И т.д. и т.п.

В>>>>·>Тем, что НЕЧТЫ надо между собой как-то идентифицировать ещё до сохранения на сервере.
В>>>>Они же либо пачкой отправляются, либо отдельными запросами.
В>>·>Т.е. ты должен неявно отправить N штук и потом ждать N назад, сопоставляя по очередности. Вариант, конечно, но опять всё сломается при сетевых ошибках, да и не очень очевидно в чём преимущества.
В>>Не знаю про ваших клиентов, но у меня за такое отвечает библиотека, которая выполняет запросы. Или среда исполнения.
·>Т.е. запросы неявно идентифицируются библиотекой или средой исполнения. Та же ж только в профиль.
Да, это называется HTTP + твоя клиентская библиотека/среда исполнения. Каждый запрос возвращается именно к тому, кто его отправил изначально. Даже в асинхронном виде.
Гуиды никуда это не денут.

В>>>>В любом случае ты получишь ответ соответсвующий каждому из них. Даже, если это асинхронно выполнять.
В>>·>Асинхронно вообще бардак начаться может, если, скажем, сервер работает в нескольких экземплярах и в итоге запросы могут обрабатываться не по порядку.
В>>Ну и что? Вернуться же они куда надо и кому надо.
·>Не волшебным же способом, а используя некую идентификацию.
Стандартный механизм, который всё равно будет работать без учёта наличия или отсутствия гуидов.

Здравствуйте, Ватакуси, Вы писали:
В>Соединение или есть или его нет. Пакеты/макеты, это не существенно. И даже если у тебя гуид, без соеденения ты ничего не сдеаешь.
К сожалению, выделенное неверно. Это было бы очень круто, если бы интернет позволял получать такой код ошибки, который говорит "сервер совершенно точно не получил ваш запрос", или "сервер совершенно точно получил ваш запрос, но мы не смогли доставить его ответ".

В>>>Если оно есть, то повтор. Далее через 200, 201 или 409 можно управлять "пониманием".
S>>Ну, и как вы собрались управлять этим пониманием через 200, 201, 409?
В>Как угодно. Зависит от логики и требования. В чём именно сложности?
Сложности — именно в том, что клиент в принципе не способен отличить ситуацию "сервер запрос не получил, изменений не внёс" от ситуации "сервер запрос получил, изменения внёс".
Вот, расскажите мне, как вы собираетесь обрабатывать запрос типа "создать новую транзакцию для перевода 1000 долларов со счёта 1 на счёт 2" — по каким критериям будете возвращать 201 или 409?

Все сценарии с генерацией ID на сервере должны принимать во внимание возможность потери этого самого ID.
Контрпримеры я лично наблюдал, и в самых продвинутых компаниях, и в не очень древние времена. Был, в частности, у Microsoft ровно такой АПИ — типа POST-запрос "создать подписку", а в ответ — ID этой подписки.
И если ты этот ID потерял — то всё, пинцет. Создаётся лишняя подписка, никак тебе не видимая.

И это вовсе не воображаемая проблема — у одного из клиентов, который с этим API работал, под закрытие проекта накопилось под тысячу вот таких вот "мёртвых душ". А самое стрёмное — что их даже обнаружить очень тяжело. Потому что эти вот ID ни в какой отчётности не фигурировали; просто в конце месяца инвойс не сходится на некоторую сумму денег, а за счёт чего именно — хз.

S>>Для начала серверу нужно как-то научиться отличать запрос клиента "сохрани ещё один заказ" от "я не понял, ты вот этот заказ уже сохранил?"
В>Речь же не идёт про те редкие случаи, когда нет возможности определить есть объект в базе или нет.
Что значит "есть объект в базе или нет"? Как вы это собираетесь определять, не имея ID объекта?

Здравствуйте, Ватакуси, Вы писали:
В>Начал отлично, но закончил как всегда.
В>Суррогатный ключ нужен в редких случаях, с этим согласен?
В редких 99% случаев.

В>Повторюсь. Если даже ты шлёшь гуиды свои, то всё равно (за редким исключением) придётся делать логику на уникальность объекта. Это никуда не денется. Вообще никуда.
Это будет совсем другая логика.
Потому, что если я второй раз пытаюсь сделать PUT на создание города с ID=123 и названием=Новосибирск, то это 201. А если я пытаюсь сделать PUT с ID=128 и названием=Новосибирск, то это 409.
Иначе клиент не может отличить ситуацию "Я пытаюсь создать ещё один город с существующим названием" от "одна из моих предыдущих попыток, которые мне показались неудачными, на самом деле завершилась успехом".

В>По "натуральному".


В>Там, где у тебя не чашки. А например документы. С уникальными именами. Или возврат налогов (который только один в один финансовый год). И т.д. и т.п.
Уникальность имён документов — иллюзия. Scope у этой уникальности какой?

В>·>Т.е. запросы неявно идентифицируются библиотекой или средой исполнения. Та же ж только в профиль.
В>Да, это называется HTTP + твоя клиентская библиотека/среда исполнения. Каждый запрос возвращается именно к тому, кто его отправил изначально. Даже в асинхронном виде.
В>Гуиды никуда это не денут.
Это просто означает, что ваша магическая среда исполнения делает за вас то, что вам кажется ненужным. То есть она сначала генерирует идентификаторы запросов на клиенте (и скорее всего это именно GUID), а уже потом отправляет их на сервер. А вы делаете вид, что ничего этого нету, и гарантии идемпотентности обеспечиваются какой-то чудесной магией.

В>Стандартный механизм, который всё равно будет работать без учёта наличия или отсутствия гуидов.
Он будет работать не без учёта, а на основе гуидов.

Здравствуйте, Anton Batenev, Вы писали:
AB>Размер ключа конечно влияет, но на больших табличках его влияние незначительно за счет размера связанных данных.
Это было бы очень странно. Промежуточные страницы (а их — примерно половина) состоят из ключей и ссылок на страницы, которые обычно укладываются в 4-8 байт. Поэтому именно размер ключа определяет показатель логарифма.
AB>Ты можешь провести подобный же эксперимент с random uint64 — результат будет плюс-минус одинаковый (в сравнении со вставкой в хвост).
При случае попробую.
AB>Если интересно, то можно почитать еще вот это: store-uuid-optimized-way. А вообще подобных исследований и докладов на всяких HighLoad-подобных конференциях в то время было достаточно много, если покопаться.
Да, очень интересно.
S>> Более того, вставка в конец гарантирует fill-factor в 50%
AB>IRL заполнение будет близко к 100% — так же легко подтверждается натурным экспериментом.
Вот это тоже очень интересно — как они это делают? В B-Tree сплит делит страницу ровно пополам. Есть подозрения, что авторы там специальным образом оптимизируют монотонный случай ценой нарушения инварианта B-дерева.
Странно, что нет никакой статьи с подробным объяснением "чем отличается наш индекс от настоящего B+-дерева".

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

В>·>Это называется натуральный ключ. И это таки ключ генерируемый на клиенте. Да, если бизнес-сущность имеет натуральный ключ, то можно использовать его. Если такого ключа нет, то придётся использовать гуид — суррогатный ключ.
В>Начал отлично, но закончил как всегда.
В>Суррогатный ключ нужен в редких случаях, с этим согласен?
Очень зависит от предметной области.

В>·>При этом у тебя размазывается логика между клиентом и сервером. Клиент должен точно знать что сервер считает натуральным ключом, чтобы восстанавливаться после сбоя. В случае с гуидом — поля будут просто поля. И сервер может отвечать на попытку сохранения документа — "успех" или "дубликат", контролируя логику проверки дубликатов. Называется разделение обязанностей: идентификатор идентифицирует документ для синхронизации между клиентом и сервером, а значения полей, в т.ч. их уникальность в определённом разделе, етс — это относится к валидации данных документа.
В>Как же она размазывается, если это основа всех основ?
В>Повторюсь. Если даже ты шлёшь гуиды свои, то всё равно (за редким исключением) придётся делать логику на уникальность объекта. Это никуда не денется. Вообще никуда.
Уникальность объекта может быть логически нетривиальной, меняться со временем, эволюционировать с изменением требований и даже быть неодинакова между клиентом и сервером. А иногда вообще нет никакой уникальности, примеры с заказами и банковскими операциями тут уже были неоднократно. А гуид он и в африке гуид. Повторюсь: разделение обязанностей.

В>>>·>Это как? Модели чего? Проблема в рассинхронизации между клиентом и сервером. Сервер не знает что у клиента, клиент не знает что у сервера.
В>>>Ну, спрашиваещь базу, кэш или что-нибудь ещё есть у меня такой объект с такими полями или нет.
В>·>Т.е. запрос по какому-то ключу.
В>По "натуральному".
Т.е. усложнение решения на пустом месте.

В>>>·>Это не то что идея, это неизбежный вариант.
В>>>Ну, прислал ты два разных ID, но объекты 100% одинаковые. У тебя база или служба ВСЁ РАВНО должны это обработать. Тогда зачем платить больше?
В>·>Да — и мне выдали две мои заказанные одинаковые чашки кофе. Не понял где платится больше.
В>Там, где у тебя не чашки. А например документы. С уникальными именами. Или возврат налогов (который только один в один финансовый год). И т.д. и т.п.
Это не идентификация документа, а валидация. Да, вроде бы один в год, но вдруг потом внезапно выяснится, что поданную декларацию можно отозвать, и засабмитить по новой, иметь несколько драфтов или ещё чего.

В>>>·>Т.е. ты должен неявно отправить N штук и потом ждать N назад, сопоставляя по очередности. Вариант, конечно, но опять всё сломается при сетевых ошибках, да и не очень очевидно в чём преимущества.
В>>>Не знаю про ваших клиентов, но у меня за такое отвечает библиотека, которая выполняет запросы. Или среда исполнения.
В>·>Т.е. запросы неявно идентифицируются библиотекой или средой исполнения. Та же ж только в профиль.
В>Да, это называется HTTP + твоя клиентская библиотека/среда исполнения. Каждый запрос возвращается именно к тому, кто его отправил изначально. Даже в асинхронном виде.
В>Гуиды никуда это не денут.
Повторяю. HTTP не гарантирует возврат ответа. И даже доставку запроса. Если у тебя сокет прервался — без гуидов туши свет. А ещё как клиенты, так и серверы могут падать и перезапускаться в самые интересные моменты времени.
Ещё есть аспект масштабирования. Внезапно может понадобится, что вместо одного http соединения у тебя будет пачка и там уже возвращаться что попало куда попало может.


В>·>Не волшебным же способом, а используя некую идентификацию.
В>Стандартный механизм, который всё равно будет работать без учёта наличия или отсутствия гуидов.
Или не будет работать без гуидов.

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

S>>Ну потому что хотя бы по REST все ресурсы должны быть уникальны и глобальны.
В>Ты уверен? Точно?
В>Но даже если это предположить, то опять как это связано с гуидами?

Гуиды создавались для обеспечения глобальности и уникальности.

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

С> S>Как он отличит ситуацию "запрос потерян на пути к серверу" от ситуации "ответ потерян на пути от сервера"?
С> Меня не оставляет чувство, что некоторые участники дискуссии не знакомы с делопроизводством с его "входящими" и "исходящими" номерами обращений.
Во-первых, неясно какое это имеет значение в контексте REST, там один запрос и один ответ. Нумеровать собственно нечего.
А во-вторых, номера сообщений — это и есть идентификаторы, только локальные в данной сессии соединения. Цирк начинается когда сессия обрывается и приходится пересоединяться, тогда эти номера плывут и вообще хз что значат.
Ещё интересно в скалируемых системах, когда отвечать могут разные инстансы серверов.

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

S>Для начала серверу нужно как-то научиться отличать запрос клиента "сохрани ещё один заказ" от "я не понял, ты вот этот заказ уже сохранил?".

Т.е. если на клиенте "подделать" GUID — отослать повторный запрос с тем же GUID и другими данными, то можно изменить результат уже проведённой операции с интересными финансовыми последствиями?

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

BFE>Т.е. если на клиенте "подделать" GUID — отослать повторный запрос с тем же GUID и другими данными, то можно изменить результат уже проведённой операции с интересными финансовыми последствиями?
Нет, нельзя. Сервер, построенный по REST канонам, получив повторный запрос с тем же GUID и другими данными, вернёт 409 conflict.

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

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

Мне тоже такое не нравится. Но иногда это нужно. Например, когда БД локально у разных пользователей (или на разных серверах), а их нужно синхронизировать.

В>Я уже молчу про 80 символов в строке (макс.) и вертикальное форматирование.
В>У меня экран на 90% пустой!

Это просто дурь и пережиток прошлого.

А я вот привык к табличному форматированию. Но наши гуйщики его не приняли. Говорят мешает смотреть кто код правил, так как хреновые бэймы не понимают, что менялись только пробелы.

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

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


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

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

Было, но как и в случае выше, возникло из-за дырок, возникших из-за неоптимального алгоритма генерации в специфических случаях (при импорте внешних данных).

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

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


вот этот момент поясните пожалуйста.
имеется ввиду, что закончатся айдишники в табле для генерации и надо новый сервер?

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

e> вот этот момент поясните пожалуйста.
e> имеется ввиду, что закончатся айдишники в табле для генерации и надо новый сервер?

Закончится CPU/RAM/IO (в любой комбинации) и увеличение пропускной способности при помощи апгрейда одиночного сервера в сравнении с разделением на несколько серверов станет экономически нецелесообразным.

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

AB>Здравствуйте, e.thrash, Вы писали:

e>> вот этот момент поясните пожалуйста.
e>> имеется ввиду, что закончатся айдишники в табле для генерации и надо новый сервер?

AB>Закончится CPU/RAM/IO (в любой комбинации) и увеличение пропускной способности при помощи апгрейда одиночного сервера в сравнении с разделением на несколько серверов станет экономически нецелесообразным.

а типа гуид уникальный будет на всю пачку серверов в большой системе, а айди на каждом сервере свой будет?