Я буду использовать поле с именем ID; целочисленный первичный ключ. Нужно ли указывать второе уникальное поле, чтобы иметь возможность восстанавливать таблицы, если некоторые поля/отношения ID перепутаны или это не вызывает беспокойства?База данных; Один или два уникальных поля?
Я использую auto-increment integer, с базой данных Sql-CE. Один пользователь.
Я действительно не понимаю вашу мотивацию, чтобы добавить второе уникальное поле ID - зачем? Какая польза от этого?
Что вам нужно, это ID, которая является уникальной, стабильной, и в состоянии четко идентифицировать каждую отдельную строку и может служить в качестве первичного ключа - в SQL Server INT IDENTITY делает это отлично.
Я не вижу смысла или выигрыш в добавлении второй уникальный идентификатор для каждой строки ...
Каждая таблица имеет один или несколько ключей-кандидатов. Выберите один из них для первичного ключа; добавьте УНИКАЛЬНЫЕ ограничения на другие, чтобы обеспечить семантическую корректность. Это не имеет никакого отношения к тому, чтобы восстановить таблицу, если что-то «перепуталось».
У вас также должны быть индексы столбцов, которые содержатся в предложениях WHERE, чтобы сделать доступ как можно быстрее. Это конкретные случаи применения/использования.
Пример того, что я имею в виду, это таблица адресов. У вас может быть суррогатный первичный ключ. У вас также есть индексы для различных комбинаций zip, city, province, county и т. Д., Чтобы сделать SELECT эффективными. Вы также можете захотеть, чтобы комбинация street1/stree2/city/province/zip была UNIQUE. Зависит от вашей бизнес-проблемы.
Если требуется семантика вашей таблицы, добавьте еще несколько уникальных ключей, которые могут вам понадобиться. Например, если в вашей проблемной области все сущности «Employee» уникально идентифицированы по имени, тогда имя должно иметь уникальный индекс или ограничение на него. Если могут быть два сотрудника с одинаковым именем, то, конечно, не должно быть ограничений уникальности для этого столбца.
У меня теперь есть клиент, которому необходимо хранить информацию в школе за год. Им нужно уникальное ограничение (или индекс) в столбцах школы и года, вместе взятых. Иногда эти два являются также первичным ключом, но даже когда они не являются первичными, они уникальны.
В таблице должно быть столько ключей, сколько необходимо для обеспечения целостности данных. Если «ИД» в этом случае означает суррогатный ключ, тогда ответ «да», вы, как правило, должны иметь естественный ключ для обеспечения уникальности в правильно нормированной базе данных, иначе вы могли бы дублировать значимые бизнес-данные. Если вы определяете суррогатные ключи перед естественными ключами, тогда я думаю, что вы принимаете ошибочный подход к дизайну.
Критерии выбора ключей: знакомство, простота и стабильность. Добавьте суррогатные ключи к своей модели только тогда, когда и где у вас есть все основания, учитывая возможные недостатки и дополнительную сложность.
Резервирование ради резервного копирования может быть целесообразным.
Однако большинство людей не реализуют его, загружая избыточные столбцы в таблицы схем, как указывает ваш вопрос. В этом есть много накладных расходов, и есть много режимов сбоев, когда дублирующийся идентификатор становится прикрученным в то же самое время, когда главный идентификатор закручивается.
Возможно, вам лучше разработать таблицы истории, которые отслеживают историю идентификаторов в течение некоторого ограниченного промежутка времени. Многие люди проектируют таблицы истории в качестве промежуточной области для хранения в автономном режиме, и в базе данных сохраняется только недавняя история. Такая история может быть связана с другими проблемами в дополнение к тому, что вас интересует.
Ну, если отношение было потеряно из-за того, что база данных испортила первичные ключи родительской таблицы, то это не способ восстановить отношения , если никакое другое поле не имеет поля, соответствующего полю родительской таблицы. Таким образом, данные тогда бесполезны. Это все моя мотивация. Но я спрашиваю об неопытности. Если вы скажете мне; нет, никто никогда этого не делает, тогда хорошо, я могу просто забыть идею :) – bretddog
Например, если я регистрирую некоторые данные за каждый день, а также у меня есть набор событий в этот день, хранящихся в другой таблице. У меня будет дневной стол и таблица событий. У дня были бы поля: ID, Date, SomeParameter. Событие имеет поля: ID, DayID, Note1, Note2. В этом случае я не сохраняю дату в таблице событий. Если бы я это сделал, это были бы дубликаты данных, я думаю. Но это также означает, что существует только существующее отношение - это внешний ключ DayID. – bretddog