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

← →
Anatoly Podgoretsky © (2006-04-17 16:05) [160]

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

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

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

> просто ИНН превратится логически в UID

1. вот и придумывай алгоритм придумывания новых ИНН если оный "умрет".
2. вот и храни 10(+длина строки) знаков вместо 4 (int).
а надо оно?

← →
Jeer © (2006-04-17 16:17) [162]

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

1. PK - это способ идентификации записи в пределах таблицы, не более того.
С этой точки зрения, что СК, что EK - неважно, т.к. не стоит задача идентификации с внешним миром.
1а - РК на основе СК и связки таблиц на основе СК - "естественнее" для СУБД.
2. ЕК, тем более составной ЕК, привязанный к изменчивому внешнему миру и есть основной источник головной боли.
3. Систематизации и на ее основе разумная унификация ничего, кроме лучших понимания и управляемости системы принести не может.
"Или не тот корм был в коня" (С)
4. В принципе, СК и ЕК - это разные уровни абстракции одного и того же - прикладных данных, но, как правило, с использованием СК система работает быстрее, проектирование ведется единообразнее (тот самый универсализм).

← →
Jeer © (2006-04-17 16:19) [163]

Anatoly Podgoretsky © (17.04.06 16:05) [160]

Переехал чел из Воркуты в Москву - смотришь и новый ИНН достался.
А чел. один и тот же.
Где уж тут уникальность.

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

Jeer © (17.04.06 16:19) [163]

Раз он переехал, то какой смысл его учитывать ?

Jeer © (17.04.06 16:17) [162]

> 1а - РК на основе СК и связки таблиц на основе СК - "естественнее"
> для СУБД.

Что значит - естественнее ? С точки зрения СУБД абсолютно безразлично, какой первичный ключ - всего лишь поле или набор полей в таблице.

> 2. ЕК, тем более составной ЕК, привязанный к изменчивому
> внешнему миру и есть основной источник головной боли.

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

> 3. Систематизации и на ее основе разумная унификация ничего,
> кроме лучших понимания и управляемости системы принести
> не может.

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

← →
Sergey13 © (2006-04-17 16:30) [165]

2[164] Игорь Шевченко © (17.04.06 16:27)
Ты часто упоминаешь "рамках конкретных задач", " неизменным в рамках задачи сущностям". Но эти "рамки" - одно из самых непостоянных условий во внешнем мире, которые касаются программистов. 8-)

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

Sergey13 © (17.04.06 16:30) [165]

Ну не знаю. Если предметная область устойчивая, то откуда возьмется непостоянность ?

← →
Jeer © (2006-04-17 16:38) [167]

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

> Раз он переехал, то какой смысл его учитывать ?

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

> С точки зрения СУБД абсолютно безразлично,

Еще как различно:)
СУБД - она к машинке ближе, а там integer в почете.

> У СУБД голова не болит, как ты понимаешь.

Зато болит у разработчика при смене реалий по два раза на день.

> Составной просто неудобен,

Не просто, а очень, т.к. балшой и СУБД его на быстро скушает.

> а всякая ли изменчивость должна поддаваться учету в рамках
> конкретных задач ?

Если это о том, что на каждый чих органов должны выделяться деньги на его вытирание -это утопия.
Сказано сменить план счетов ?
Сделано.
Всем ли оплачено - некоторым.

> или потерей производительности.

справочники, как правило невелики по объему, ссылки же по связкам-integer эффективнее для СУБД, т.е быстрее.

Все это - как правило.
Исключения мизерны, а потому - ничтожны.

← →
Sergey13 © (2006-04-17 16:41) [168]

2[166] Игорь Шевченко © (17.04.06 16:35)
>Ну не знаю. Если предметная область устойчивая, то откуда возьмется непостоянность ?

Так вот например, было как

[163] Jeer © (17.04.06 16:19)
Переехал чел из Воркуты в Москву - смотришь и новый ИНН достался.

[164] Игорь Шевченко © (17.04.06 16:27)
Раз он переехал, то какой смысл его учитывать ?

А потом решили распространить Воркутинский опыт и потребовалось все слить "в мировом масштабе".

Да мало ли. ПисАли "складик для себя", а потом получилось почти "ERP на продажу".

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

Jeer © (17.04.06 16:38) [167]

> Имеет, т.к. он мог переехать в пределах одной учетной базы
> и формально будет два налогоплательщика, но один чел.

Тогда все зависит от того, как его, переехавшего надо учитывать. Пока ты не ответишь на этот вопрос, дальнейшая дискуссия нецелесообразна.

> Еще как различно:)
> СУБД - она к машинке ближе, а там integer в почете.

Точно ? А вот в MSSQL, по публикациям, GUID рекомендуют. А он и вовсе не Integer. Да и ROWID у Oracle тоже не Integer. Поэтому что там куда ближе - это еще бабушка надвое сказала.

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

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

> Зато болит у разработчика при смене реалий по два раза на
> день.

Зачем их менять, два раза в день, реалии-то ? :) Ну в упор не понимаю.

> ссылки же по связкам-integer эффективнее для СУБД, т.е быстрее.

Эта...Ходят слухи, что СУБД внутре себя integer"ы не используют для идентификации записей в таблицах...

← →
Jeer © (2006-04-17 16:48) [170]

В общем, хотелось бы завершить данную полемику тем, что выбор СК vs ЕК - вопрос практический или философский, но не теоретический, т.е. формальных методов обоснования предпочтения пока не видно.

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

Jeer © (17.04.06 16:48) [170]

Вот с этим я безусловно соглашусь :)

← →
Jeer © (2006-04-17 16:54) [172]

> Точно ? А вот в MSSQL, по публикациям, GUID рекомендуют.
> А он и вовсе не Integer.

> Ходят слухи, что СУБД внутре себя integer"ы не используют
> для идентификации записей в таблицах...
>

Реализации они разные бывают, да и что Микрософту лишние гигабайты.

А проверить легко - тестик:
Таблицы:
ФАМИЛИИ (char 32)
ИМЕНА (32)
ОТЧЕСТВА (32)
ПЕРСОНАЛ(Ф,И,О, ИНН)

Один вариант на СК, другой на ЕК
записей по 100 на справочники и 500 тыс на ПЕРСОНАЛ

Вот и проверка будет:)

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

Jeer © (17.04.06 16:54) [172]

> Таблицы:
> ФАМИЛИИ (char 32)
> ИМЕНА (32)
> ОТЧЕСТВА (32)
> ПЕРСОНАЛ(Ф,И,О, ИНН)
>
> Один вариант на СК, другой на ЕК
> записей по 100 на справочники и 500 тыс на ПЕРСОНАЛ

Если честно - не понял. Ты предлагаешь Фамилии хранить в отдельной таблице, Имена в отдельной таблице ? А зачем ? :)

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

Это пример работы со справочниками, как соответствующий реальности.

← →
VictorT © (2006-04-17 17:15) [175]

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

Теоретически - да, а практически - то ли алгоритму не всегда следуют, то ли фиг знает какие причины, но неоднократно видел совпадения (неднократно - это десятки раз).

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

Jeer © (17.04.06 17:09) [174]

Объем данных - это одна половина вопроса. Вторая половина - это характер запросов к этим данным. Я не уверен, что заранее, не зная задачи, склонюсь к использованию естественных или искусственных ключей.

← →
Jeer © (2006-04-17 17:22) [177]

Выборки по:
- фамилии
- фам + имени
- ф + и + о

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

Jeer © (17.04.06 17:22) [177]

В таком случае я, скорее всего, выберу естественные ключи.

← →
euru © (2006-04-17 17:42) [179]

Странный спор.

Я знаю одну большую систему, работающую не только в нашей стране. Так там успешно применяются оба типа РК. И, вроде бы, никаких проблем эта система не испытывает.

Об чём же тогда спор?

← →
Внук © (2006-04-17 19:15) [180]

>>Игорь Шевченко © (17.04.06 11:05) [80]
А спорить не надо, просто приведи хоть одну причину делать естественный первичный ключ, кроме непонятной любви к мазохизму.
Первичный ключ, допускающий редактирование пользователем - страшный сон. Но любителям приключений, в отличие от пуристов - удачи.

← →
Внук © (2006-04-17 19:20) [181]

>>Игорь Шевченко © (17.04.06 12:48) [93]
>>Любые разумные доводы обычно принимаются, а с религией спорить - нуегонафиг.
Есть и еще доводы, кроме уже приведенных (которых и так выше крыши). Но я опять подозреваю тебя в споре ради спора :)

← →
Внук © (2006-04-17 19:29) [182]

Sergey13 © (17.04.06 13:26) [118]
В точку.

← →
euru © (2006-04-17 20:31) [183]

> Внук © (17.04.06 19:15) [180]
>
> >>Игорь Шевченко © (17.04.06 11:05) [80]
> А спорить не надо, просто приведи хоть одну причину делать
> естественный первичный ключ, кроме непонятной любви к мазохизму.
>
Номер документа + Дата проводки
Позволяет сократить количество операторов JOIN, которые неминуемо бы появились, будь у каждого документа суррогатный автоинкрементный код.

← →
Lamer@fools.ua © (2006-04-17 20:42) [184]

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

Можно пояснить это на примере? Я что-то не вижу причин для уменьшения количества JOIN"ов.
К тому же, судя по слову "проводка" речь идёт о бухгалтерской системе? Если да, то ещё вопрос: а если документ ещё не проведен, а только пока что сохранён?

← →
Внук © (2006-04-17 20:42) [185]

Каким образом вид ключа влияет на количество операторов JOIN? Правда, не понимаю. Суррогатный ключ, состоящий из одного поля, наоборот упрощает связи. А вот связывать таблицы по информационным полям... Брр.

← →
Внук © (2006-04-17 20:52) [186]

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

← →
xayam © (2006-04-17 23:59) [187]

> euru © (17.04.06 17:42) [179]
> Странный спор.
>
> Я знаю одну большую систему...И, вроде
> бы, никаких проблем эта система не испытывает.
>
> Об чём же тогда спор?

Вопрос был не в том испытывает она проблемы по жизни или нет, вопрос в способности системы (базы данных) к адаптации к изменениям в реальной жизни (ИНН, ISO... ... ...). Если Вы используете Естеств.Ключ могу Вас поздравить - гемороя не оберетесь (еще раз повторю [30]: а оно Вам надо?), при наличии же Сур.Ключа эти изменения сведены к минимуму.

> Игорь Шевченко ©

[90] -1
[98] -1
[111] -1
[115] -1
[121] -1
[131] -1
[134] -1
...дальше не читал...итого < -7

← →
Суслик © (2006-04-18 00:39) [188]

> xayam © (17.04.06 23:59) [187]

поддерживаю.

---------------

повторю, что для меня единственное место ествественного ключа (как я понимаю, это когда в PK включается не уникальный суррогат, а значение) это junction table - таблица связи в отношении многие ко многим.

> Суслик © (18.04.06 00:39) [188]
> это когда в PK включается не уникальный
> суррогат, а значение

PK по определению уникальный каким бы он ни был, ЕК или СК

Внук © (17.04.06 20:52) [186]

> Насчет пресловутого кода ISO. Как я уже сказал - есть такой
> справочник у нас. В действительности, сделай мы это поле
> первичным ключом - то есть обязательным для ввода - рисковали
> бы остановить работу программы, что в нашем случае чревато
> серьезными проблемами вплоть до потери заказчика.

А зачем вы пишете такие программы ? Я бы не стал тратить время.

Внук © (17.04.06 19:15) [180]

> А спорить не надо, просто приведи хоть одну причину делать
> естественный первичный ключ

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

xayam © (17.04.06 23:59) [187]

> Вопрос был не в том испытывает она проблемы по жизни или
> нет, вопрос в способности системы (базы данных) к адаптации
> к изменениям в реальной жизни

Примеры адаптации в студию. Без примеров твои слова пустой звон.

> ...дальше не читал...итого < -7

Вот и хорошо, арифметику усвоил.

>>Игорь Шевченко © (18.04.06 10:14) [190]
>>А зачем вы пишете такие программы ?
Вот в этом, скорее всего, и корень спора. Видишь ли, если писать и продавать коробочный продукт, то можно следовать заветам всяких Бекусов и братьев их Науэров. Подходит продукт заказчику - берет, не подходит - ну и ладно. Мы же пишем всегда под конкретного заказчика, поэтому система обречена на развитие, сопровождение, ввод новых версий, подгонку под капризы и т.д. В данном случае естественные ключи даже на очевидных справочниках - куча проблем. Можно спорить, но я больше верю собсвтенному опыту, чем абстрактным рассуждениям.

Внук © (18.04.06 10:24) [192]

Да кто бы спорил - заказчики, они такие. Но какое отношение поведение заказчиков имеет к сабжу, я честно не понимаю.

Внук © (17.04.06 20:52) [186]

> естественные ключи чреваты - как из-за нестабильности законодательства

Дорогой Саша, на свете, кроме бухгалтерии, существует еще масса не менее увлекательных предметных областей.
"Их тоже следует убивать" (с) Страж-птица.

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

Я бы не сказал, что они такие уж редкие. Почему, интересно, авторы книжек по СУБД не рекомендуют, все как один, использовать исключительно синтетические ключи ? Они в другом мире живут ?

>>Игорь Шевченко © (18.04.06 10:32) [193]
А я не понимаю, какое отношении имеет частный случай, когда ЕК не несет проблем, к преимуществам и недостаткам обсуждаемых методик.

Внук © (18.04.06 10:38) [195]

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

2[196] Игорь Шевченко © (18.04.06 10:54)
> У естественных ключей преимущество в первую очередь в простоте программирования
А чем проще то? Или в чем сложность СК?

to Игорь Шевченко © (18.04.06 10:54) [196]:
>У естественных ключей преимущество в первую очередь в простоте
>программирования
Если естественный ключ составной, то программирование не упрощается, а только усложняется.

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

IMHO, очень спорное утверждение. Почему, когда я пишу JOIN в запросе, я должен вспоминать, по какому полю (или, упаси Аллах, полям) мне нужно соединять таблицы в ON?

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