WiskyЕсли так коробит от корректировки первичного ключа, CODE является PK, а ID уникальный с сортировкой совпадающей с Value

...и на ID ссылается таблица с полмиллиардом записей. Веселое такое поле для сортировки.

Dima Tschiпропущено...


Главное, что они однозначны во всех базах данных, в отличие от автоинкрементов и GUID-ов.
Где-то удалось два одинаковых гуида получить?

А несколько ИНН у одного человека обычное явление: у Akina их два 21372901 , у моего знакомого три 21372749

Хуже, когда наоборот. Я знал, как двум людям одинаковый ИНН выдали - потом одного чуть не посадили за грехи другого.

Leonid Kudryavtsevmayton...Как вообще ключевать физ-лицо?...

По фотке или отпечаткам пальца (как более простой методе ))) )

У меня в военном личном деле всю жизнь была чужая фотография.
Новобранцев постригли, пофоткали - все на одно лицо.

И с отпечатками пальцев все не так гладко. У некоторых людей они не выражены столь явно, чтобы применить средства распознавания. Я знаю людей, которые не могут пользоваться сканером отпечатка пальца на ноутбуке. Не узнает он их, хоть тресни.

schimaytonВ топике звучала верная мысль о том что в качестве ПК лучше брать суррогат
На основе sequence. Все прочие способы нас приведут к аномалиям. Будут
Смены паспортов, ИНН, страховок.

Joe Celko на тебя нет.
http://www.sql.ru/forum/507537/stil-programmirovaniya-dzho-selko-na-sql

При всем уважении к Celko, глава "Автонумерация не может использоваться в качестве реляционного ключа" у него достаточно спорная.

Книга его передо мной бумажная, поэтому цитаты печатаю вольно и кратко, саму суть.

Аргументы против SEQUENCE-суррогатов у него такие:

Joe Celko1. Автонумерация является нестандартной функцией, поэтому ждите проблем при миграции на другой продукт.

Определенные различия между серверами, конечно же, есть, но это скорее вопросы к практике миграции, чем к теории проектирования БД.

Этак можно про большинство фич сказать - в разных серверах с датой, деревьями и BLOB'ами работают разные функции, давайте не использовать дат, деревьев и BLOB'ов вообще, и давайте сидеть в рамках ANSI-SQL-89, потому что он поддерживается всеми серверами.

Joe Celko2. Тип данных IDENTITY нельзя присвоить двум столбцам таблицы, и это ужасно. Если тип данных нельзя присвоить более чем одному столбцу, это вообще не тип данных.

Верно, но это скорей забавный логический парадокс реляционной философии, чем реальная проблема. Одного столбца IDENTITY достаточно, и трудно представить, зачем нужен второй.

Joe Celko3. Если сделать таблицу с одним столбцом, и тот - автонумерация, мы не сможем вставить что захотим, и не можем менять значения. Что же это за таблица, что в нее ни вставить, ни поменять?

Опять же, этот вырожденный случай - проблема философов от SQL, но никак не реальной жизни.

Joe Celko4. Если вставлять N строк в таблицу с автонумерацией одной командой INSERT...SELECT, то строки пронумеруются в непредстазуемом порядке, согласно физическому порядку на диске, а всего вариантов их нумерации может быть N! (факториал), и это ужасно. В действительности все еще хуже - при следующей вставке они могут пронумероваться в другом порядке! Как ужасно! Как объяснить, что тем же самым строкам присвоены другие номера? В реляционной модели строки, содержащие одинаковый набор атрибутов, должны обрабатываться одинаково.

Выделенная цитата - точная, он так и говорит, и тут бы я поспорил. Дело в том, что в реляционной модели порядок записей не имеет значения для реляционных операций. Другими словами, две выборки, отличающиеся только порядком записей - считаются тождественно равными. Поэтому верная в целом мысль Joe Celko, именно к порядку записей - относиться не должна.

Дальше он приводит примеры, как в таблицу вводят ключ ID, но не добавляют больше никаких ограничений уникальности, и сокрушается, что в нее можно добавить кучу дублей. Ну так это же не ID виноват, а отсутствие UNIQUE(ssn, vin), или что там у него.

В конце он с умным видом приводит цитату из Кодда. Но по смыслу Кодд говорит именно о проблемах использования естественных ключей, так что это гол скорее в ворота самого Celko. В целом глава тянет скорее на разбор некоторых типичных ошибок проектирования, чем на методические обобщения.