Сообщение Re[16]: Ключи в базе - гуиды, 80 символов и прочая чухня от 07.12.2021 13:25
Изменено 07.12.2021 13:28 gyraboo
Re[16]: Ключи в базе - гуиды, 80 символов и прочая чухня
Здравствуйте, ·, Вы писали:
В>>>>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот 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 и ответ. В чём сложность?
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 и работать приятнее, нет того неприятного ощущения что он "чуховый" и "коллизийный", чем с каким-то непонятным гуидом, который сгенерён по непонятному алгоритму.
Re[16]: Ключи в базе - гуиды, 80 символов и прочая чухня
Здравствуйте, ·, Вы писали:
В>>>>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот 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 и ответ. В чём сложность?
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 и работать приятнее, нет того неприятного ощущения что он "чуховый" и "коллизийный", чем с каким-то непонятным гуидом, который сгенерён по непонятному алгоритму.