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