Новое сообщение в форум Философия программирования

Форум	Философия программирования
Тема	Как правильно задавать вопросы

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

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

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

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

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

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

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

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail