Здравствуйте, 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, там один запрос и один ответ. Нумеровать собственно нечего.
А во-вторых, номера сообщений — это и есть идентификаторы, только локальные в данной сессии соединения. Цирк начинается когда сессия обрывается и приходится пересоединяться, тогда эти номера плывут и вообще хз что значат.
Ещё интересно в скалируемых системах, когда отвечать могут разные инстансы серверов.