Пожалуйста, подтвердите мое использование первичного ключа и уникального индекса

Question

Мне кажется, я понимаю первичные ключи и индексы.

В моей настройке у меня есть таблица с несколькими столбцами.Два из этих столбцов: ИД пользователя и Имя пользователя.В идеале мне бы хотелось, чтобы оба были уникальными и не могли иметь значения NULL.

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

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

Это то, что я буду делать, если не будет способа сделать оба столбца уникальными и не равными NULLABLE?

Answer 1

Вы можете объявить столбец имени пользователя как NOT NULL и поместить в него уникальный индекс.Хотя сам индекс не будет принудительно устанавливать значения, отличные от NULL, определение поля будет таким образом, поэтому оно будет фактически уникальным ненулевым значением.

Answer 2

Полностью согласен с Майклом, ваш столбец первичного ключа не должен содержать каких-либо значимых данных, особенно таких как userID. Таким образом, вы должны добавить еще один столбец для PK и заполнить его из последовательности.

Также согласен с Darhazer: вы должны установить ненулевое ограничение и уникальный индекс как для полей userid, так и username.

Answer 3

Нет, извините, что вы ошиблись в обоих аккаунтах.

1) Право на все, кроме того, что PK может измениться, если вы этого хотите.

2) Уникальный индекс по определению уникален, его нельзя повторить. То, что вы имеете в виду, это обычный старый индекс, а не уникальный, который можно повторить. Его цель - ускорить выполнение запросов, если вы часто фильтруете по этому полю. В противном случае лучше не использовать его.

Что вы хотите: Столбец1 = Первичный ключ (не ноль), Столбец2 = Уникальный индекс (не ноль), именно то, что вы сказали, но теперь вы знаете, почему он работает так, как вам нужно.

РЕДАКТИРОВАТЬ: Кроме того, кажется, вы делаете корреляцию между индексами и необнуляемыми. Вы можете сделать столбец необнуляемым независимо от того, является ли он индексом или нет.

Answer 4

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

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

Кроме того, в Интернете это откроет людям, которые видят URL-адреса вроде ....user/1/details, а затем потенциально могут изменить «1» на «2» (например) и увидеть информацию о других людях.Лучше, если идентификатор уникален, например «57489574389ghfjghfjghf», и тогда будет сложнее взломать URL-адреса.

Выбор между «естественным» и «суррогатным» ключом хорошо объяснен здесь:
http://www.agiledata.org/essays/keys.html

Большинство проблем, с которыми люди сталкиваются в этой области, относятся к крайним случаям, таким как слияния и удаления.Обычно они изначально имеют низкий приоритет, но со временем их беспокойство будет расти, а плохо спроектированные решения начнут выходить из строя (обычно потому, что в момент, когда качество данных «распознается»), часто бывает такой большой объем «плохих» данных, чтопродвижение вперед несостоятельно - старые данные не могут быть «исправлены», и без этого трудно ввести правила для новых записей, которые будут сосуществовать с ними. Это предполагает, что возможность обновления старых записей все еще требуется.