Существует ли уникальный номер записи в таблице?

[smoyk]

To salminenp
Сам навик его не делает, но его можете сделать вы, благо навик предостовляет возможности создания автоинкрементных полей. При необхонимости это поле можно сделать и ключевым.

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

p.s. Сам я на естественные ключи не наезжаю, иногда можно (серия+ № паспорта к примеру), но у себя в таблицах всетаки предпочитаю и использую автоинкримент.

[Yoil]

Цитата:

Сообщение от smoyk

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

Насчет во-первых, не согласен. Вот как раз и получится в итоге, что вставили в документ две строки с одним номером, а автоинкремент увеличился, все в поряде, система не ругнулась.
Насчет во-вторых... Ну да, меньше занимает. Но это, имхо, мелочь.
Насчет в-третьих - согласен, тяжелая штука. С другой стороны, если бы это самое RU-RUS не являлось первичным ключом, руками бы писали изменение этого значения во всех связанныз таблицах? Ну тогда и вместо ренейма можно запись удалить, вставить новую и аналогично неким скриптом пробежаться по всем связанным табличкам.

[rov_imported]

Внесу и я свои 5 копеек к рублю Дуда!

Цитата:

Сообщение от smoyk

гарантирует уникальность каждой записи и отсутствие ошибки при добавлении записи типа "Запись уже существует".

А кто вам сказал, что такая ошибка должна отсутствовать? Простейший тупой пример из Навижн: есть табличка Общая настройка Учета - ее первичный ключ пересечение значений Общая бизнес группа и Общая товарная группа. Если пользователь создает запись, ошибочно указав уже имеющиеся значения бизнес и товарной группы - что будет при инкременте? Запись создастся, правда? А ничего, что система ЗАТОЧЕНА на отсутствие подобных повторений? Это - ее бизнес-логика.

Цитата:

Сообщение от smoyk

Во-вторых, автоинкрементный первичный ключ занимает меньше места в БД, по сравнению с естественным.

Как вы думаете естественный ключ просто так создается их определенных полей? Наверное ведь нет? Наверное
эти поля потом буду использоваться: при фильтровке, сортировке и пр. Значит и при инкрементном ключе вам понадобится по-любому создать дополнительные ключи из "естественных" полей. То есть был один ключ(естественный)-а стало 2: автоинкрементный и естественный. Что то я не уловил - и в каком случае будет меньше места,а?

Цитата:

Сообщение от smoyk

Для примера: справочник ОКСМ, первичное поле - код страны, у страны "Россия" вбили "RU", примерно через годик код "России" изменился на "RUS" и у вас появились проблемы. Или "RU" вбили по ошибке. Не важно. Этот пример просто для примера.

А вот здесь пожалуй да, соглашусь - случай тяжелый. Если бы вместо естественных полей везде стояли ссылки на инт-вые ключи - то не надо все везде переименовывать. Однако тут же в голове возникает образ подчиненной записи - набор инт-вых ссылок на мастер-таблицы. С такой базой будет невозможно работать.
Продали товар 1, клиенту 2, со склада 3, через журнал продаж 4, продал пользователь 5!
Офигенно информативно!