Я был пользователем mysql/postgres, и обеспечение уникальности первичного ключа БД кажется мне естественным, пока я не обнаружил, что снежинка не обеспечивает уникальность первичного ключа. Это также имеет смысл, поскольку, если таблица не такая большая, приложение, которое выполняет вставку, всегда может проверить уникальность самого первичного ключа, и обычно приложение не использует первичный ключ для вставки.
Если это понимание правильное, когда имеет смысл позволить БД обеспечивать уникальность первичного ключа? Я предполагаю, что когда приложение проверяет уникальность перед вставкой + время фактической вставки медленнее, чем использование БД для обеспечения уникальности и просто вставки напрямую.
«всегда» — это то же самое, что и каждый раз, когда вы хотите ничего не думать и иметь плохую производительность.
База данных "проверяет для вас" и "вы делаете проверку" должна стоить одинаково. Хотя вы могли бы сделать это хуже.
Но дело в производительности: никогда не делайте того, что вам не нужно. Итак, если вы дедуплицировали некоторые данные на шаге A, а затем вставили в таблицу B, как БД узнает, что ограничения не нужно проверять ... это не так, поэтому он должен проверять снова. и снова, и снова.
В Oracle, чтобы добиться производительности, вы тратите некоторое время на отключение ограничений. А потом снова. Теперь это кажется несколько рискованным.
Итак, в «Снежинке» нет бесплатного обеда, но также нет и скрытого налога, и я знаю таких людей, которые в полной мере относятся к легкому углеводному чувству бесплатного обеда. Но я не хочу этого.
Потому что кодер может ошибаться, а БД нет. Кроме того, зачем усложнять свой код, чтобы выполнять то, что может автоматически сделать за вас БД? Ответ на вопрос, который вы задали в заголовке, Всегда.