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

[rov_imported]

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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