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

← →
Jeer © (2006-04-17 13:31) [120]

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

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

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

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

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

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

← →
Игорь Шевченко © (2006-04-17 13:37) [121]

Jeer © (17.04.06 13:31) [120]

> Из соображений единообразности работы с таблицами все же
> ввести ID (PK)

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

> Такая структура таблицы
> ID
> [IDL]
> NAME
> UID
> DATER
>
> была использована как базовый класс.

Если ты еще напишешь, какой физический смысл каждого из полей, будет о чем поговорить.

← →
Sergey13 © (2006-04-17 13:37) [122]

2[119] Игорь Шевченко © (17.04.06 13:28)
> Здрасьте вам. Это как же живые ключи не в любой системе возможны ? :)
Сори, неправильно выразился.
Вместо
>А живые ключи не в любой системе возможны.
Надо
А живые ключи будут надежно работать НЕ в любой системе.

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

Sergey13 © (17.04.06 13:37) [122]

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

← →
Jeer © (2006-04-17 13:41) [124]

> Игорь Шевченко © (17.04.06 13:37) [121]

> Какой выигрыш они дают ?

пример я уже приводил.
Если не введены ограничения на уровне механизма СУБД (их нет или по другим соображениям) - то ID позволяет "автоматически проявлять" изменения в ISO во всех связанных документах.

← →
Игорь Шевченко © (2006-04-17 13:42) [125]

Sergey13 © (17.04.06 13:37) [122]

Казалось бы, чего проще - вот есть у каждой таблицы ROWID (в случае с Oracle), вот это и есть первичный ключ. А для ссылочных полей, на уровне СУБД были бы реализованы механизмы поддержки целостности. Чем плохо ? А вот не делают почему-то...

← →
Jeer © (2006-04-17 13:43) [126]

Пример
ISO (ID,NAME)
BOOKS (ID, ISO_ID,NAME)

← →
Jeer © (2006-04-17 13:43) [127]

> вот есть у каждой таблицы ROWID (в случае с Oracle),

Своеврмененное уточнение.

← →
Sergey13 © (2006-04-17 13:48) [128]

2[123] Игорь Шевченко © (17.04.06 13:40)
Ну вот Оракл не разрешает штатно апдейтить каскадно ключи. Это косвенно и показывает, что не надо естественные использовать. 8-)
Кроме того - а как бы они (производители) отличали естественный от суррогата? По имени что-ли? Так фигня вроде получится. Если вводить новый тип поля - ключ, то вроде надо делать что-то вроде автоинкремента - что не всегда удобно и лишает разработчика свободы формирования ключа по собственной схеме-алгоритму.

← →
Sergey13 © (2006-04-17 13:50) [129]

2 [125] Игорь Шевченко © (17.04.06 13:42)
>Казалось бы, чего проще - вот есть у каждой таблицы ROWID (в случае с Oracle), вот это и есть первичный ключ.
Он может являться таковым для одномоментной обработки - типа проапдейтить запись. Однако в более длительный период времени ROWID может меняться и потому не может быть ключом для связей.

← →
Jeer © (2006-04-17 13:57) [130]

Sergey13 © (17.04.06 13:50) [129]

> автоинкремента

> ROWID может меняться

По этой же причине и autoinc "опасен"

← →
Игорь Шевченко © (2006-04-17 13:59) [131]

Sergey13 © (17.04.06 13:48) [128]

> Кроме того - а как бы они (производители) отличали естественный
> от суррогата?

А никак. Вводили бы только суррогатный и всех дел.

> Ну вот Оракл не разрешает штатно апдейтить каскадно ключи.
> Это косвенно и показывает, что не надо естественные использовать.
> 8-)

Ну, во-первых, никто не мешает реализовать такой апдейт в триггере путем insert|delete.

Jeer © (17.04.06 13:41) [124]

> - то ID позволяет "автоматически проявлять" изменения в
> ISO во всех связанных документах.

А по какой причине эти изменения возникнут, что их надо "автоматически проявлять" ?

Jeer © (17.04.06 13:43) [126]

> Пример

Извини, не понимаю. Если не затруднит, то для бестолковых два раза и помедленнее.

← →
Суслик © (2006-04-17 14:01) [132]

> [111] Игорь Шевченко © (17.04.06 13:05)
> > Да почему? ИНН это одно, налогоплательщик другое.
> > Если убрать номера автомашин, то что машины уберутся?
> Нет, машины не уберутся. Но отличить их одну от другой станет
> заведомо труднее.

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

← →
Игорь Шевченко © (2006-04-17 14:01) [133]

Sergey13 © (17.04.06 13:50) [129]

> Он может являться таковым для одномоментной обработки -
> типа проапдейтить запись. Однако в более длительный период
> времени ROWID может меняться и потому не может быть ключом
> для связей.

Как ты понимаешь, никто не мешает разработчику сделать неизменяемый ROWID.

> Так фигня вроде получится. Если вводить новый тип поля -
> ключ, то вроде надо делать что-то вроде автоинкремента
> - что не всегда удобно

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

← →
Игорь Шевченко © (2006-04-17 14:03) [134]

Суслик © (17.04.06 14:01) [132]

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

← →
Sergey13 © (2006-04-17 14:05) [135]

2[131] Игорь Шевченко © (17.04.06 13:59)
>А никак. Вводили бы только суррогатный и всех дел.
Что значит "вводили бы"? Сами что-ли? Так это типа чистый автоикремент, который нельзя узнать до вставки (и вообще управлять им нельзя) и потому неудобен для работы.

> Ну, во-первых, никто не мешает реализовать такой апдейт в триггере путем insert|delete.
Так никто не спорит, что можно обойти. Но штатно нельзя.
Кроме того не хотел бы я ждать завершения подобной (тригерной) перекодировки на приличной по размерам базе. 8-)

← →
vuk © (2006-04-17 14:06) [136]

to Игорь Шевченко:
>Давай будем брать не ИНН - пес с ним, а тот самый вариант с кодировкой
>географии по ISO. Тоже будем ID вводить ?
На это я уже ответил.
см. vuk © (16.04.06 18:32) [65]

← →
Sergey13 © (2006-04-17 14:07) [137]

2 [133] Игорь Шевченко © (17.04.06 14:01)
> Как ты понимаешь, никто не мешает разработчику сделать неизменяемый ROWID.
Это как? Запретить узеру работать с базой что-ли?

← →
Jeer © (2006-04-17 14:07) [138]

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

> А по какой причине эти изменения возникнут, что их надо
> "автоматически проявлять" ?

По причине изменения стандарта (RUS изменилось на RAS)

Пример
ISO (ID,NAME)
BOOKS (ID, ISO_ID,NAME)

select B.*, I.NAME AS ISO_NAME
from BOOKS B, ISO I
where B.ISO_ID = I.ID

ISO_NAME всегда будет иметь измененное знчение из ISO.NAME для произвольно взятой СУБД (не использование ограничений)
т.к. меняется не первичный ключ, а прикладное поле.

← →
Jeer © (2006-04-17 14:09) [139]

vuk © (17.04.06 14:06) [136]

Во !
Почитал vuk и понял что мы об одном и том же - одинаково.:))

← →
Суслик © (2006-04-17 14:10) [140]

> [134] Игорь Шевченко © (17.04.06 14:03)

Ты разницу между "База налогоплательщиков" и "База людей получивших ИНН?" понимаешь?

← →
Игорь Шевченко © (2006-04-17 14:16) [141]

Jeer © (17.04.06 14:07) [138]

> По причине изменения стандарта (RUS изменилось на RAS)

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

vuk © (17.04.06 14:06) [136]

Ответил. Но я честно не понимаю, с какого боку тут однородность методики идентификации записей. Почему тогда производители СУБД не делают штатно такую возможность ? Наш форум не читают ?

Sergey13 © (17.04.06 14:05) [135]

> Что значит "вводили бы"? Сами что-ли? Так это типа чистый
> автоикремент, который нельзя узнать до вставки (и вообще
> управлять им нельзя) и потому неудобен для работы.

Вот замечательно. А как ты суррогатным ключом управляешь ?

> > Как ты понимаешь, никто не мешает разработчику сделать
> неизменяемый ROWID.
> Это как? Запретить узеру работать с базой что-ли?

Зачем запрещать ? А что, пользователь непременно ROWID меняет при своей работе с базой данных ?

← →
Игорь Шевченко © (2006-04-17 14:16) [142]

Суслик © (17.04.06 14:10) [140]

Я понимаю. А какое отношение твоя фраза к теме ветки имеет ?

← →
vuk © (2006-04-17 14:34) [143]

to Игорь Шевченко © (17.04.06 14:16) [141]:
>Но я честно не понимаю, с какого боку тут однородность методики
>идентификации записей.
А при том. Чтобы не было как в той байке - "здесь играть, здесь не играть, здесь рыбу заворачивали".

>Почему тогда производители СУБД не делают штатно такую возможность ?
Естественных ключей иногда хватает, а иногда нет. Принуждать всегда пользоваться искусственными тоже неправильно.

← →
Суслик © (2006-04-17 14:39) [144]

> Я понимаю. А какое отношение твоя фраза к теме ветки имеет
> ?

Ты игнорируешь невыгодные тебе в данном контексте доводы. Например, довод о том, что база "Налогоплательщиков" никакого отношения к ИНН не имеет: налогоплательщики есть, а есть ли у них ИНН это вопрос другой. Вот у меня и сложилось ощущение, что разница между базой "Налогоплательщиков" и "Людей получивших ИНН" тебе не совсем ясна или просто ты не обратил на эту разницу внимания. И я посчитал своим долгом обратить на это внимание человека, который принимает участие в данной конкретной ветке. Вроде объяснил.

← →
Sergey13 © (2006-04-17 14:39) [145]

2 [141] Игорь Шевченко © (17.04.06 14:16)
> Вот замечательно. А как ты суррогатным ключом управляешь ?
Очень просто. Я могу например менять диапазон значений ключа в зависимости от внешних факторов (например для разграничения филиалов для "а-ля" репликации) . Я могу заранее узнать следующее значение ключа для вставки связанных данных. И т.п.

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

← →
Игорь Шевченко © (2006-04-17 14:47) [146]

vuk © (17.04.06 14:34) [143]

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

Ты сказал! (с) Евангелие.

Ключевая фраза - "Естественных ключей иногда хватает". Об чем, собственно, большевики и твердят на протяжении всей этой ветки.

> А при том. Чтобы не было как в той байке - "здесь играть,
> здесь не играть, здесь рыбу заворачивали".

Ты сам себе не противоречишь ? :)

Суслик © (17.04.06 14:39) [144]

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

> Ты игнорируешь невыгодные тебе в данном контексте доводы.
>

У меня, дорогой Дима, вообще никакой выгоды от этой дискусии нет. Ни я никого не принуждаю, ни меня никто не принуждает.

Sergey13 © (17.04.06 14:39) [145]

> Он его может изменить штатными незапрещенными методами.
> Например импорт/экспорт или перенос данных на другой диск
> и многими другими.

Точно также сгенерированный суррогатный ключ после экспорта /импорта может потерять смысл.

← →
Sergey13 © (2006-04-17 14:49) [147]

2Sergey13 © (17.04.06 14:39) [145]
> Точно также сгенерированный суррогатный ключ после экспорта /импорта может потерять смысл.
Почему?

← →
vuk © (2006-04-17 14:55) [148]

to Игорь Шевченко © (17.04.06 14:47) [146]:
>Об чем, собственно, большевики и твердят на протяжении всей этой ветки.
А я, собственно, это сомнению и не подвергал.

>Ты сам себе не противоречишь ? :)
Нет.

Sergey13 © (17.04.06 14:49) [147]

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

Дабы всем была понятна моя позиция, я ее озвучу: Всякий овощ приносит пользу, будучи употреблен надлежащим образом в надлежащее время. Естественные ключи в ряде случаев являются удобными к применению и смысла не употреблять их только потому, что в других случаях они неудобны, я не вижу. Более того, если бы ествественные ключи были бы однозначно неудобны/чреваты последствиями, то производители СУБД давно бы сделали прозрачный механизм для связи таблиц. Поскольку я такого механизма не наблюдаю в тех СУБД, с которыми приходится иметь дело (Interbase, Oracle), то следовательно, либо производители этого не делают, либо я чего-то искать не умею.

2[149] Игорь Шевченко © (17.04.06 14:56)
>Например по причине совпадения значений ...
Это если в лоб делать все_равно_какой экспорт в непустую таблицу (я, применительно к ROWID, говорил о полном импорте/экспорте схемы/БД). Для тех же филиалов с диапазонами ключей экспорт в "общую БД" пройдет нормально и без коллизий.

>Дабы всем была понятна моя позиция, я ее озвучу
8-)

McSimm © (17.04.06 14:57) [150]

> потому что покинул границы целостности данных

Если autoinc - да.
Вот почему их не люблю:))

Игорь Шевченко © (17.04.06 14:16) [141]

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

Нет, прикладная сущность не изменилась - все та же Russia, но код поменялся.
Наличие CR позволяет, в данной ситуации, внести изменение только в справочник.

Игорь Шевченко © (17.04.06 14:56) [149]

Это частное мнение.
Точно с таким же - считаю, что наличие искусственных хотя и усложняет join, но в конечном итоге приводит к большим устойчивости, корректности, производительности.
Для коротких естественных ключей - все понятно, можно использовать, но с учетом универсальности - имеет смысл перейти на искусственные.
Длинные естественные ключи - источних проблем при миграции во ВК.
Они вообще - проблема, эти ЕК, т.к. являются порождением внешней среды, а не БД.

Jeer © (17.04.06 15:17) [152]

> Нет, прикладная сущность не изменилась - все та же Russia,
> но код поменялся.

По какой причине код поменялся ? :)

> Для коротких естественных ключей - все понятно, можно использовать,
> но с учетом универсальности - имеет смысл перейти на искусственные.
>

Вот чего я не могу понять - это привлечение в качестве аргумента "универсальности". Любое попытка универсализировать что-либо в большинстве случаев приводит к неэффективности и прочим побочным эффектам. Как говорится в законах Мэрфи - всякое решение плодит новые проблемы.

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

> По какой причине код поменялся ? :)

Это не суть.

> Любое попытка универсализировать

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

Кроме, того СК являются более гибким решением и позволяют вести пере- до-проектирование системы с меньшими потерями.

А вообще-то СК vs ЕК - давно отнесено к войнам религиозного типа.
А проектировщики СУБД не отдают предпочтения чьей-либо стороне по философским убеждениям.:)

Jeer © (17.04.06 15:32) [154]

> Это не суть.

Нет, Сергей, именно в этом и суть. Просто так ничего не может меняться и всякое подобное изменение может (а в большистве случаев и должно) повлечь за собой изменение в алгоритме.

> Кроме, того СК являются более гибким решением и позволяют
> вести пере- до-проектирование системы с меньшими потерями.
>

Не вижу причины, почему бы не использовать естественные ключи при перепроектировании системы.

> является попыткой систематизации, в первую очередь

Если внесение лишних сущностей называется систематизацией, то я, извини, против такой систематизации, потому как побочным эффектом от такой огульной систематизации является головная боль.

2[156] Игорь Шевченко © (17.04.06 15:42)
> Если внесение лишних сущностей называется систематизацией, то я, извини, против такой систематизации
Так то "лишних сущностей". А СК - не лишний, он дополнительный и независимый. 8-)
А первоначально, многие ЕК были обычными СК. Потом к ним привыкли и они стали естественными. Те-же ИНН, номера паспортов и тому подобная билиберда. 8-)

Sergey13 © (17.04.06 15:53) [157]

> Так то "лишних сущностей". А СК - не лишний, он дополнительный
> и независимый

Ну да. Дополнительным является пятое колесо в телеге :)

2[158] Игорь Шевченко © (17.04.06 15:58)
> Ну да. Дополнительным является пятое колесо в телеге :)
Пятое колесо - это запаска! Я без нее не рискну выехать. 8-)

Суслик © (17.04.06 12:49) [96]
Не будет завтра ИНН. И что?

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

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