Первичный ключ

← →
Игорь Шевченко © (2006-04-17 11:05) [80]

Внук © (16.04.06 10:56) [62]

> Будем вводить. По причине номер раз - для однообразия правил
> формирования таблиц, по причине номер два - для половины
> вводимой информации операторы не знают этих кодов, и знать
> не хотят.

Я ж говорю - с пуристами спорить - себе дороже. Зачем прах Оккама тревожить ?

vuk © (16.04.06 18:32) [65]

> Оно конечно да, но ведь этот ключ в базе потом наверняка
> еще и как внешний будет использоваться. А про то, что ИНН
> могут неверно вбить уже говорили.

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

> В конце концов можно посмотреть на проблему иначе. Уникальна
> конкретная личность, а ИНН - некий атрибут который ей государство
> присвоило и не дело нашей БД, что оно там присвоило и как
> сгенерило.

И, прости, в чем разница, государство сгенерировало или механизм СУБД ?

← →
sniknik © (2006-04-17 11:37) [81]

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

← →
Игорь Шевченко © (2006-04-17 11:40) [82]

sniknik © (17.04.06 11:37) [81]

Может, я чего здорово не понимаю, но в чем именно сложность ?

← →
Игорь Шевченко © (2006-04-17 11:44) [83]

Кроме того, в случае синтетического ключа мне, теоретически, никто не мешает внести несколько одинаковых, ничем не отличающихся сущностей. Например, толпу людей с одинаковыми ИНН, ФИО и т.п.

← →
Jeer © (2006-04-17 12:19) [84]

Игорь Шевченко © (17.04.06 11:44) [83]

Уникальный индекс ?

А вообще поддерживаю применение СК (по другому и не делал похоже никогда).

← →
Игорь Шевченко © (2006-04-17 12:24) [85]

Jeer © (17.04.06 12:19) [84]

И зачем умножать сущности сверх необходимости ? Тенцера я читал, так что сслку на него в качестве аргумента можно не приводить

← →
Jeer © (2006-04-17 12:28) [86]

Игорь Шевченко © (17.04.06 12:24) [85]

> зачем умножать сущности сверх необходимости

Для отделения мух от котлет.

> Тенцера я читал

Не сомневаюсь, однако это известно задолго до появления Тенцера.

← →
Sergey13 © (2006-04-17 12:30) [87]

2[85] Игорь Шевченко © (17.04.06 12:24)
>И зачем умножать сущности сверх необходимости ?
Что бы обеспечить себе спокойную старость. 8-)
Ибо ничто не вечно под луной. (с)тырено
Сегодня есть ИНН, завтра нет его, а есть супер-ИНН. Мало ли.

← →
vuk © (2006-04-17 12:34) [88]

to Игорь Шевченко © (17.04.06 11:05) [80]:
>Вбить могут неверно все, что угодно. И какая разница, неверно вобьют ИНН
>или имя, с точки зрения базы данных ?
>И, прости, в чем разница, государство сгенерировало или механизм СУБД ?
Мантра есть такая: "Foreign key... Foreign key..." :)
Имя мы уж точно в качестве PK не будем использовать, а вот к чему приведет использование криво вбитого ИНН в качестве FK, я думаю, понятно. Конечно, можно поставить опцию каскадных обновлений.
Ну и еще, если говорить об ИНН в качестве PK, то можно вспомнить, что не у всех оно есть.
Про то, что кто-то может предпочесть не использовать в своей БД чужие идентификаторы в качестве ключевых, я уже упоминал. У нас, например, именно так и есть.

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

← →
McSimm © (2006-04-17 12:34) [89]

жизнь немножко сложнее и непредсказуемее, чем твердая логика СУБД. логика "государства" тоже может отличаться от логики вообще...

все это может зависеть от конкретной задачи, конечно. могу добавить несколько аргументов кроме уже приведенных в пользу СК, на примере ИНН

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

← →
Игорь Шевченко © (2006-04-17 12:40) [90]

Jeer © (17.04.06 12:28) [86]

> Для отделения мух от котлет.

С этого места подробнее, где мухи, а где котлеты ?

Sergey13 © (17.04.06 12:30) [87]

> Сегодня есть ИНН, завтра нет его, а есть супер-ИНН. Мало
> ли.

И что ? Я не понимаю, можно на примере пояснить ?

vuk © (17.04.06 12:34) [88]

> Мантра есть такая: "Foreign key... Foreign key..." :)

Да, каждое утро распеваем хором. И что с того ? Давай будем брать не ИНН - пес с ним, а тот самый вариант с кодировкой географии по ISO. Тоже будем ID вводить ?

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

Наверное все-таки непонятно, к чему приведет пользование криво вбитого ИНН. Расскажи.

← →
McSimm © (2006-04-17 12:44) [91]

> к чему приведет пользование криво вбитого ИНН

сложно вносить изменения в поля первичного ключа.
в различных СУБД различная степень сложности

> вариант с кодировкой географии по ISO

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

← →
boriskb © (2006-04-17 12:47) [92]

Объясните мне о чем спор?
О том, что существует (и не мало) случаев, когда в качестве первичного ключа можно использовать информативное поле базы? В этом есть сомнения?

Или спор о том, что чаще всего удобно использовать автоинкриментный ключ? Об этом тоже надо спорить?

← →
Игорь Шевченко © (2006-04-17 12:48) [93]

McSimm © (17.04.06 12:44) [91]

> сложно вносить изменения в поля первичного ключа.
> в различных СУБД различная степень сложности

То есть, существуют СУБД, которые не позволяют изменить значение поля первичного ключа ? Или не обеспечивают соотвествующего обновления подчиненных таблиц ? :)

> кроме религиозных соображений

Об том, собственно, и речь. Любые разумные доводы обычно принимаются, а с религией спорить - нуегонафиг.

← →
Суслик © (2006-04-17 12:48) [94]

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

← →
Игорь Шевченко © (2006-04-17 12:48) [95]

Суслик © (17.04.06 12:48) [94]

Ты свое имхо пояснишь ?

← →
Суслик © (2006-04-17 12:49) [96]

> [95] Игорь Шевченко © (17.04.06 12:48)

> Ты свое имхо пояснишь ?

Про ИНН? Все просто. У меня вызывают сурьезные опасения последовательность принимающих законы в своих действиях. Не будет завтра ИНН. И что?

← →
Jeer © (2006-04-17 12:50) [97]

Игорь Шевченко © (17.04.06 12:40) [90]

> С этого места подробнее, где мухи, а где котлеты ?

мухи - системный уровень (ID, relations)
котлеты - прикладной уровень.

Наличие и уникальность индекса по "котлетам" гарантирует от пользовательских ошибок, в данном случае.

← →
Игорь Шевченко © (2006-04-17 12:50) [98]

Суслик © (17.04.06 12:49) [96]

Не будет ИНН - будет другая база, не так ли ?

← →
Суслик © (2006-04-17 12:51) [99]

> [98] Игорь Шевченко © (17.04.06 12:50)

почему?
Люди живы (или контрагенты), работают там же, какого лешего новая база?

← →
Jeer © (2006-04-17 12:51) [100]

Игорь Шевченко © (17.04.06 12:48) [93]

> Или не обеспечивают соотвествующего обновления подчиненных
> таблиц ? :)

А то:)

← →
Sergey13 © (2006-04-17 12:52) [101]

2[90] Игорь Шевченко © (17.04.06 12:40)
>И что ? Я не понимаю, можно на примере пояснить ?
Да ничего хорошего. Тут либо оставлять "старый ИНН" первичным ключом, но сделать его генеримым в системе, либо заполнять "новый ИНН" у всех записей (сколько их? Когда мы их все получим от клиентов?) и "переводить" систему на него. ИМХО, мало не покажется.
В случае с сурогатом - просто добавим еще одно поле и пропишем правила его заполнения.

>а тот самый вариант с кодировкой географии по ISO. Тоже будем ID вводить ?
Для некоторых данных, возможно, "живой" ключ вполне приемлем. Но, как правило (это из личного опыта), это данные второстепенные - небольшие справочники со стандартизованными данными.

← →
Jeer © (2006-04-17 12:55) [102]

Sergey13 © (17.04.06 12:52) [101]

> со стандартизованными данными.

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

← →
McSimm © (2006-04-17 12:57) [103]

> То есть, существуют СУБД, которые не позволяют изменить
> значение поля первичного ключа ? Или не обеспечивают соотвествующего
> обновления подчиненных таблиц ? :)

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

на мой взгляд доводов достаточно.
легче изменять, можно не вводить (временно или вовсе. например если речь идет о клиентах, работать с ним уже надо, а ИНН пока отсутствует. из жизни)
Про разграничение доступа довод тоже на мой взгляд не пустой. Насколько я понимаю, ИНН - приватная информация. и легко представить ситуацию, когда не все имеющие доступ к справочнику клиентов имеют право видеть все поля.

← →
Игорь Шевченко © (2006-04-17 12:57) [104]

Суслик © (17.04.06 12:51) [99]

> почему?

Ну потому что. Очевидно же, что идентификация по ИНН годится только для вполне вполне определенного ряда задач, а не для пихания ИНН в качестве первичного ключа во все возможные дырки. Пропадет индивидуальный номер налогоплательщика - те задачи потеряют смысл, не так ли ?

Jeer © (17.04.06 12:50) [97]

> мухи - системный уровень (ID, relations)
> котлеты - прикладной уровень.

Мухами в данном случае ведает сама СУБД. Всякие там constraints и прочее.

> Наличие и уникальность индекса по "котлетам" гарантирует
> от пользовательских ошибок, в данном случае.

А ты на примере можешь пояснить ? Желательно из тех областей, которые здесь приводились. От каких ошибок может гарантировать внедрение уникального синтетического ключа ?

← →
Суслик © (2006-04-17 12:58) [105]

> Пропадет индивидуальный номер налогоплательщика - те задачи
> потеряют смысл, не так ли ?

не так ли (и не имхо), налогоплательщик то остался.

← →
McSimm © (2006-04-17 13:00) [106]

> идентификация по ИНН годится только для вполне вполне определенного
> ряда задач

согласен.
это может быть, например, сама база налогоплательщиков.

← →
Суслик © (2006-04-17 13:02) [107]

> согласен.
> это может быть, например, сама база налогоплательщиков.

Да почему? ИНН это одно, налогоплательщик другое.
Если убрать номера автомашин, то что машины уберутся?

← →
Суслик © (2006-04-17 13:03) [108]

> согласен.
> это может быть, например, сама база налогоплательщиков.

Скорее не "налогоплательщиков", а "налогоплательщиков, получисших ИНН".
Это верно

McSimm © (17.04.06 12:57) [103]

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

Извини, не понимаю. Можно иллюстрацию ?

> Насколько я понимаю, ИНН - приватная информация. и легко
> представить ситуацию, когда не все имеющие доступ к справочнику
> клиентов имеют право видеть все поля

То есть, когда он на кассовом чеке печатается, там приватность не имеет значения, а когда в базе данных, то имеет ? :)

И еще, ко всем - очень трудно схему базы данных рассматривать в отрыве от задач, решаемых с ее помощью. Для общих случаев одинаково неверны и те и другие рекомендации, чаще всего.

> Для общих случаев одинаково неверны и те и другие рекомендации,
> чаще всего.

совершенно согласен

Суслик © (17.04.06 13:02) [107]

> Да почему? ИНН это одно, налогоплательщик другое.
> Если убрать номера автомашин, то что машины уберутся?

Нет, машины не уберутся. Но отличить их одну от другой станет заведомо труднее.

Игорь Шевченко © (17.04.06 13:04) [109]
очень трудно схему базы данных рассматривать в отрыве от задач, решаемых с ее помощью

Так и я про тоже!
Причем здесь ИНН??
Где то он может быть первичным ключом, а где то не может
Разве это не очевидно?

Игорь Шевченко © (17.04.06 12:57) [104]

> Мухами в данном случае ведает сама СУБД. Всякие там constraints
> и прочее.

Если может, то - да.
Но иногда и не может:))
А чаще и constraint не помогает и лучше на ХП или на клиенте делать ограничения.

> От каких ошибок может гарантировать внедрение уникального
> синтетического ключа ?

Не синтетического, а сложного индекса по прикладным полям.

2[109] Игорь Шевченко © (17.04.06 13:04)
> Извини, не понимаю. Можно иллюстрацию ?
Оракл не дает апдейтить каскадно ключ по констрейнту. Можно конечно извратиться, но если по диапазонам ПК, например, настроены партиции, то прикинь во что выльется подобная перекодировка.

Jeer © (17.04.06 13:11) [113]

> А чаще и constraint не помогает и лучше на ХП или на клиенте
> делать ограничения

Странно. А зачем тогда их (constraints) придумали ? :)

> Не синтетического, а сложного индекса по прикладным полям.

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

Из личных ощущений и практики:

- ФК применяется тогда, когда целесообразно сохранять историю "введения" поля в связанные документы
Пример:
Есть таблица ФАМИЛИИ
Если используется ФК, то в таблицу ПЕРСОНАЛ попадает именно фамилия, а дальнейшее изменение ее в таблице ФАМИЛИИ не приводит к автоматическому изменению в ПЕРСОНАЛ.
Т.е. имеем связь на момент добавления записи в ПЕРСОНАЛ и ее отсутствие в остальное время.
Применение СК же в этом случае приведет к автоматическому изменению фамилии во всех связанных по ID документах.

- СК применяется во всех остальных случаях.

2[109] Игорь Шевченко © (17.04.06 13:04)
> Для общих случаев одинаково неверны и те и другие рекомендации, чаще всего.
Вобщем да. Но сурогаты будут надежно работать в любой системе, несмотря на некоторое возможное излищество. А живые ключи не в любой системе возможны. А еще хуже, когда сначала вроде возможны, а потом, с развитием или просто течением времени, выясняется, что...
ИМХО.

Sergey13 © (17.04.06 13:26) [118]

> Вобщем да. Но сурогаты будут надежно работать в любой системе,
> несмотря на некоторое возможное излищество. А живые ключи
> не в любой системе возможны

Здрасьте вам. Это как же живые ключи не в любой системе возможны ? :)

Игорь Шевченко © (17.04.06 13:15) [115]

Не у всех СУБД это есть, не у всех работает так, как хочется:))

> Возьмем тут же географию по ISO - какие тут можно придумать
> сложные индексы по прикладным полям, а главное, зачем ?
> :)

Из соображений единообразности работы с таблицами все же ввести ID (PK)
Сложный индекс тут и не нужен.
Но, к примеру, справочник стандартных обозначений чего-то на локальном и англ. языках - что будет PK ?

Как-то эксперементировал с объектным подходом при работе с таблицами.
Такая структура таблицы
ID
[IDL]
NAME
UID
DATER

была использована как базовый класс.

Первичный ключ Найти похожие ветки