|
To salminenp
Сам навик его не делает, но его можете сделать вы, благо навик предостовляет возможности создания автоинкрементных полей. При необхонимости это поле можно сделать и ключевым.
To Дуд
Во-первых, значение автоинкриментного числового первичного ключа присваивается СУБД автоматически, что гарантирует уникальность каждой записи и отсутствие ошибки при добавлении записи типа "Запись уже существует".
Во-вторых, автоинкрементный первичный ключ занимает меньше места в БД, по сравнению с естественным.
В-третьих и главных, проблема связи таблиц при использовании естественных ключей. Т.к. в его состав входят поля, являющиеся реальными характеристиками обьектов, вполне реальна ситуация изменения значений таких полей. В худшем случае, это ведет к нарушению целостности БД т.к. нарушаются зависимости master-detail таблиц. Этого можно избежать, задав каскадное изменение значений (как и сделано в навижине), но при этом идет полная переиндексация всех связанных записей во всех связанных таблицах. Представляете временные и ресурсные затраты в БД размером, скажем, 100 ГБ (как у нас на фирме)? Для примера: справочник ОКСМ, первичное поле - код страны, у страны "Россия" вбили "RU", примерно через годик код "России" изменился на "RUS" и у вас появились проблемы. Или "RU" вбили по ошибке. Не важно. Этот пример просто для примера.
p.s. Сам я на естественные ключи не наезжаю, иногда можно (серия+ № паспорта к примеру), но у себя в таблицах всетаки предпочитаю и использую автоинкримент.
|