База данных; Одно или два уникальных поля?

Question

Я буду использовать поле с именем ID; целочисленный первичный ключ. Есть ли смысл также указывать второе уникальное поле, чтобы иметь возможность восстанавливать таблицы, если некоторые ID поля / отношения испорчены, или это не беспокоит?

Я использую автоинкрементное целое число с базой данных Sql-CE. Один пользователь.

Answer 1

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

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

Answer 2

Резервирование ради резервного копирования может быть полезным проектом.

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

Answer 3

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

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

Answer 4

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

У вас также должны быть индексы для столбцов, которые появляются в предложениях WHERE, чтобы сделать доступ максимально быстрым.Это конкретные приложения / варианты использования.

Примером того, что я имею в виду, будет таблица адресов.У вас может быть суррогатный первичный ключ.У вас также были бы индексы для различных комбинаций zip, города, провинции, округа и т. Д., Чтобы сделать SELECT эффективными.Вы также можете захотеть, чтобы комбинация street1 / stree2 / city / провинция / zip была УНИКАЛЬНОЙ.Зависит от вашей бизнес-проблемы.

Answer 5

Я не совсем понимаю вашу мотивацию добавить второе поле уникального идентификатора - зачем ?? Какую выгоду вы видите от этого ??

Вам нужен ID, который уникален, стабилен и способен четко идентифицировать каждую отдельную строку и может служить вашим первичным ключом - INT IDENTITY в SQL Server отлично справляется .

Я не вижу смысла или выгоды в добавлении второго уникального идентификатора в каждую строку ...