Нужны ли уникальные ограничения для БД?

Question

Я удивляюсь в последнее время.Допустим, мы делаем веб-приложение с JSF + Spring + JPA / Hibernate (или другими технологиями) и допустим, что у нас есть сущность «Пользователь».Мы хотим, чтобы у пользователя был уникальный логин.Если мы хотим сделать это, тогда мы можем поместить @UniqueConstraint в столбец «Логин», но все же наше приложение должно проверять во время регистрации пользователя, является ли пользовательский ввод действительным (уникальным) или нет, без этого и только с ограничением БДмы просто получим ошибку.Это заставило меня задуматься, действительно ли ограничения БД действительно необходимы / полезны?Единственные два раза, которые я могу придумать, когда они дадут нам какую-либо выгоду, это когда кто-то пытается взломать нас (но я думаю, что наше приложение должно быть защищено от SQL-инъекций) или мы пытаемся изменить содержимое БД вручную (что не должнодействительно случится).На самом деле, теперь, когда я думаю об этом, нужны ли ограничения БД в целом / хорошая практика?Как длина строки и т. Д.

Answer 1

Для меня категорически да , см. База данных как Fotress Дэн Чак из 97 считает, что каждый архитектор программного обеспечения должен знать .Он говорит это намного лучше, чем я мог.

Answer 2

Да, они есть.Они обеспечивают целостность данных на самом низком уровне.

Возможно, вы захотите изменить содержимое БД вручную (т.е. обновить до новой версии)

Возможно, вы забудете проверить некоторые ограничения в вашем коде.

Вы можете посмотреть на это как на проверку клиент / сервер.Ваша программа - клиент, дБ - сервер.Обычно достаточно проверки клиента, но вы должны пройти проверку сервера на случай, если что-то пойдет не так.

Answer 3

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

Правда состоит в том, что приложения среднего уровня приходят и уходят, но данные живут вечно.

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

Answer 4

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

Answer 5

Часто, когда вы объявляете набор столбцов уникальным, это то, к чему вы хотите обратиться - поэтому, скорее всего, его все равно следует проиндексировать.

Да, ваша заявка должна выполнить соответствующую проверку, но что, если ошибка проскальзывает? Если ваша база данных знает, что что-то должно быть уникальным, по крайней мере, вы знаете, что не будете хранить недействительные данные (или не «плохо» недействительные данные, такие как дубликаты данных, которые должны быть уникальными). Во всяком случае, вы можете задать обратный вопрос: сколько это будет стоить?

Answer 6

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

Answer 7

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

Это самая забавная вещь, которую я когда-либо читал. Вы просто получаете ошибку? Это действительно все, что вам нужно, верно? Вы когда-нибудь слышали об ошибке? Попробуйте поймать кольцо колоколов?

На самом деле "чек" для вашего приложения очень контрпродуктивен. В любом случае база данных будет проверять ограничение, так зачем делать это дважды. Приложение должно просто вставить строку, как будто это будет хорошо. БД проверит уникальность и выдаст ошибку при сбое ... Ваше приложение должно ЛОВИТЬ эту ошибку и делать то, что вы делали в своей существующей проверке.

Answer 8

Ограничения, как уникальные, так и сторонние, не только обеспечивают целостность данных, но и влияют на производительность.Без знания этих «неформальных» констант оптимизаторы баз данных будут принимать непредсказуемые решения о том, как выполнять ваши операторы.