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

← →
Jeer © (2006-04-19 11:47) [280]

Sergey Masloff (19.04.06 11:46) [279]

Я о конкатенации:)

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

Lamer@fools.ua © (19.04.06 11:34) [271]

Ну тебя же не затрудняет запоминать слова типа AddressId ? :) Точно также, как меня не затрудняет запоминать слова CityCode

← →
Jeer © (2006-04-19 11:55) [282]

Sergey Masloff (19.04.06 11:46) [279]

Владимир Котляревский
ООП в СУБД
рекомендует GUID в пределах базы, что не лишено смысла.

← →
Jeer © (2006-04-19 11:57) [283]

Ссылка и там же есть по поводу ЕК нелестности.

http://www.ibase.ru/devinfo/oop_rdbms.htm

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

Jeer © (19.04.06 11:55) [282]

> рекомендует GUID в пределах базы, что не лишено смысла.

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

Я терпеливо следил за дискуссиями на эту тему, пока один ужасающий факт не привлек мое внимание.

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

Но, как я недавно понял, существует один важный ресурс, который, во-первых, является глобальным, а во-вторых, совершенно невосполнимым!

Я говорю о глобально уникальных идентификаторах, или UUID (также известных как GUID, CLSID, IID и др.). Как следует из документации, каждое обращение к функции WinAPI UuidCreate возвращает уникальный идентификатор! Более того, этот способ настоятельно рекомендуется к применению всякий раз, как в приложении нужно что-либо уникальное. Но ведь очевидно, что все эти идентификаторы берутся из конечного набора! И каждый вызов UuidCreate уменьшает, таким образом, количество идентификаторов, доступных всем приложениям! Стоит также заметить, что не существует никакого способа сдать использованный идентификатор обратно, когда он больше не нужен.

Самое ужасное в том, что исчерпание этого ресурса мгновенно парализует работу всех приложений, которые его используют. К несчастью, их список включает не только поделки, слепленные на коленке полуграмотными подростками. Такие серьезные продукты, как MS SQL Server, используют GUID для идентификации транзакций. На их основе работают многие сервисы, стабильность которых определяет комфорт, а иногда и жизнь людей.

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

Use the CoCreateGuid function when you need an absolutely unique number that you will use as a persistent identifier in a distributed environment.

Я вижу несколько решений данной проблемы. Скорее всего, идеально было бы сделать функцию UuidCreate платной. Даже цены в 1 доллар за 1000 GUID было бы достаточно для того, чтобы разработчики задумались о количестве идентификаторов, потребляемых их приложениями. Но пока этот сервис остается бесплатным, я призываю программистов всего мира прекратить безответственную практику использования глобально уникальных идентификаторов для короткоживущих объектов, а также для настольных приложений, в которых можно использовать альтернативные методики получения уникальных идентификаторов (например, последовательности целых чисел).

Я также собираюсь обратиться к компании Microsoft c требованием реализовать функцию UuidDestroy, которая позволит возвращать обратно ставшие ненужными уникальные идентификаторы (я даже боюсь представить это бесчисленное множество уже безвозвратно утерянных GUID!).

Если вы поддерживаете эту акцию, то напишите, пожалуйста, письмо в штаб-квартиру Microsoft в Редмонде по следующему адресу:

Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
USA"

http://rsdn.ru/article/mag/200301/GUIDEcology.xml

← →
Jeer © (2006-04-19 12:07) [285]

Игорь Шевченко © (19.04.06 12:00) [284]

Я и Котляревский не об этом, а об UID (number) - уникальном в пределах базы.

А вообще - посмеялся:)

← →
Danilka © (2006-04-19 12:10) [286]

[284] Игорь Шевченко © (19.04.06 12:00)
:))
Забавно.

Ну, вообще-то, Jeer немного ошибся, в [282], судя по хорошей ссылке в след. посте Владимир Котляревский рекомендует не именно GUID, просто уникальный ID в пределах базы, который, судя по его скриптам, имеет тип Integer.

← →
Danilka © (2006-04-19 12:11) [287]

[285] Jeer © (19.04.06 12:07)
Упс, опоздал. :)

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

Jeer © (19.04.06 12:07) [285]

> Я и Котляревский не об этом, а об UID (number) - уникальном
> в пределах базы.

Это оно все хорошо, в пределах базы (кстати, базы или таблицы?), но как быть, если необходимо одну и ту же сущность понимать одинаково во многих базах ?

← →
Jeer © (2006-04-19 12:22) [289]

..базы с таблицами

> если необходимо одну и ту же сущность понимать одинаково
> во многих базах

и странах мира:)))

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

Jeer © (19.04.06 12:22) [289]

> и странах мира:)))

Кстати да, я в 256 посте написал.

← →
Jeer © (2006-04-19 12:29) [291]

Игорь Шевченко © (19.04.06 12:26) [290]

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

← →
DiamondShark © (2006-04-19 12:34) [292]

> Игорь Шевченко © (19.04.06 12:00) [284]

GUID -- это 128 битное число.
Количество комбинаций 2^128 =~ 3e38

Если считать, что на земле живёт семь миллиардов людей, и у каждого из них есть компьютер, который круглые сутки генерирует 1000 GUID в секунду, то "кончатся" гуиды примерно через 1.5e18 лет.

Подробности для любознательных:
Время существования видимой вселенной оценивается по современным космологическим прдеставлениям в 1.5e10..2.5e10 лет.

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

Jeer © (19.04.06 12:29) [291]

> Ну Иванова в Японии тоже не знают:)

И что с того ?

← →
DiamondShark © (2006-04-19 12:41) [294]

Кстати, китайцы успешно производят и реализуют крупные партии сетевых адаптеров с одинаковыми MAC-адресами, так что все сгенерированные в мире GUIDы являются таковыми весьма условно :)

Да и вообще, IP-адреса кончатся быстрее гуидов. Так что когда развитие различных distributed environment-ов достигнет своего тупика, оставшихся гуидов как раз хватит на все первичные ключи.

:)))

← →
Lamer@fools.ua © (2006-04-19 13:32) [295]

>>Игорь Шевченко © (19.04.06 11:49) [281]

>Ну тебя же не затрудняет запоминать слова типа AddressId ? :) Точно также, как меня не затрудняет запоминать слова CityCode

Ну дык мне и запоминать-то не надо. Если объединяю таблицу tbe_Contact с таблицей tbe_Address, то сразу знаю, что в ON будет AddressID. То есть мне нужно запомнить только способ образования поля-ВК, а не само наименование поля (или что ещё хуже — наименования нескольких полей). И этот способ един в пределах всей БД.

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

Lamer@fools.ua © (19.04.06 13:32) [295]

Ради Аллаха, можно придерживаться любых правил именования, но какое отношение эти правила имеют к решаемым задачам ? Или ты не будешь решать задачи, в которых структура базы данных не будет соответствовать канонам имен ?

← →
DiamondShark © (2006-04-19 13:40) [297]

А вот в SQL Sybase ASA были замечательные конструкции: KEY JOIN и NATURAL JOIN.

KEY JOIN связывала таблицы по описанным в схеме FK, а NATURAL JOIN -- по одноимённым полям таблиц.

:)

← →
Lamer@fools.ua © (2006-04-19 14:37) [298]

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

>Или ты не будешь решать задачи, в которых структура базы данных не будет соответствовать канонам имен ?
Почему не буду? Буду. Путём рефакторинга и приведения к канонам :-))

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

Lamer@fools.ua © (19.04.06 14:37) [298]

Я задам вопрос такой, возвратившись к моей географии. Допустим, что кроме кода географического понятия по стандарту ISO, я еще решил ввести некий синтетический ключ, сообразно канонам - ID.
Для того, чтобы поддерживать его уникальность, в дополнение к уже уникальному коду, мне потребуется ввести дополнительный объект в базе данных (Sequence в Oracle, Generator в Interbase) вместе со всеми механизми его обслуживания (запрос на выборку очередного уникального значения из этого дополнительного объекта).

Внимание, вопрос - какие преимущества мне дает этот подход, кроме увеличения массы как программного кода, так и схемы базы данных ?

← →
Lamer@fools.ua © (2006-04-19 14:59) [300]

>Внимание, вопрос - какие преимущества мне дает этот подход, кроме увеличения массы как программного кода, так и схемы базы данных ?

Я как бы не в курсе полной задачи. Имеется в виду [53]? То есть задача только хранить страны? Больше ничего не надо?

← →
Lamer@fools.ua © (2006-04-19 15:00) [301]

P.S.
>То есть задача только хранить страны?
Ну и выбирать их, конечно.

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

Lamer@fools.ua © (19.04.06 15:00) [301]

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

> Я как бы не в курсе полной задачи

Пардоньте. Сторонники единообразного подхода в этой ветке говорили о преимуществах этого подхода безотносительно задач.

← →
euru © (2006-04-19 15:12) [303]

> vuk © (18.04.06 17:53) [241]
> Если нужно именно дату и номер, то надо вводить дату и номер,
> но дело в том, что обычно интерфейс проектируется так,
> чтобу вообще это дело свести к минимуму. То есть есть список
> документов на дату, где можно посмотреть любой документ,
> найти по номеру в списке и т.п. И ничего не надо вводить
> руками.

Т.е. вместо:
1. ввести номер сторнированного документа
2. получить данные этого документа
3. найти в полученном документе номер сторнирующего документа

Вы предлагаете пользователю:
1. ввести ограничивающие критерии для получения списка документов
2. дождаться получение списка
3. найти и выбрать из этого списка нужный документ
4. получить данные этого документа
5. найти в полученном документе номер сторнирующего документа

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

> > Наверно, для формирования списка сторнированных документов
> > нужно будет знать хотя бы их дату проводки, чтобы ограничить
> > этот список до разумных пределов. Получается, что JOIN переместится
> > в процедуру формирования этого списка.
>
> Если это нужно, то да, в процедуру формирования списка.
> Вопрос в том, нужно ли это.

Нужно, нужно. Иначе Вы просто выберите все сторнированные документы, которых за несколько лет работы накопилось великое множество. А это тоже вряд ли скажется на производительности.

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

Упс. Минимизация JOIN-ов -- это не условие проектирования, а следствие использования естественных ключей.
А вот использование только суррогатных ключей -- это условие проектирования, из-за которого, как Вы выразились, "можно вообще куда-нибудь не туда прийти в результате".

← →
Lamer@fools.ua © (2006-04-19 15:16) [304]

>>Игорь Шевченко © (19.04.06 15:03) [302]

>Пардоньте. Сторонники единообразного подхода в этой ветке говорили о преимуществах этого подхода безотносительно задач.
По большому счёту, так и есть.

Я предпочту один раз потратить время на то, чтобы настроить/сделать скрипт/утилиту/etc. для настройки ПК в виде identity/sequence/etc. (причём в качестве ПК буду использовать что-то родное процессору, — например, INT; GUID"ы мне не особо нравятся, если честно), чем потом при написании запросов помнить, что именно у таблицы стран ключ — ISO-код страны. Даже если пока что связей с этим справочником нет, они могут появится в будущем. А я рассматриваю системы, которые планируется расширять в будущем. Системы типа "курсовой проект, сдал и забыл" сюда не относятся, для них может использоваться несколько другой подход :-)

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

Lamer@fools.ua © (19.04.06 15:16) [304]

Я спрашивал про преимущества, вообще-то. Пусть даже с учетом расширения в будущем.

Мне кто-нибудь может ответить ?

← →
Sergey13 © (2006-04-19 15:51) [306]

2[299] Игорь Шевченко © (19.04.06 14:54)
>Внимание, вопрос - какие преимущества мне дает этот подход, кроме увеличения массы как программного кода, так и схемы базы данных ?

Никакого, кроме независимости от стандарта ISO. Стандарты ведь тоже меняются, хоть и не часто. Вдруг завтра RU станет RUS или RF.

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

Sergey13 © (19.04.06 15:51) [306]

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

> Стандарты ведь тоже меняются, хоть и не часто

Если не трудно, приведи, плз, пример изменения стандарта ISO

← →
Lamer@fools.ua © (2006-04-19 16:20) [308]

>>Игорь Шевченко © (19.04.06 15:23) [305]

Да, собственно, и преимущества и недостатки уже расписаны и у Тенцера, и в ссылке, что Вы приводили ранее. Какой мне смысл повторяться? Далее дело скорее личных пристрастий, опыта, ну и религиозных убеждений :-)

← →
Sergey Masloff (2006-04-19 16:24) [309]

Sergey13 © (19.04.06 15:51) [306]
Чаще обратная проблема. Именно из-за изменчивости стандартов.
Страна уже есть а кода - нет.

Последую примеру [149] Игорь Шевченко © (17.04.06 14:56)
и озвучу свою позицию.

Самое большое преимущество СК от ЕК - это независимость от внешнего мира. Это дает незыблемый фундамент для нерушимости связей - реляций. (о как задвинул! 8-)
Но нараду с СК в реальной БД хорошо использовать и альтернативный ключ (АК) для смысловой идентификации записи. Этот АК может состоять как из ссылок на СК, так и из ЕК.
Такое совмещение будет, ИМХО, наилучшим выходом. СК - для связей, ЕК - для поиска по таблице.

Lamer@fools.ua © (19.04.06 16:20) [308]

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

>>Игорь Шевченко © (19.04.06 16:31) [311]
Заполнить этот справочник самим разработчиком и сделать его доступным только на чтение. Нет вопросов.

Внук © (19.04.06 16:52) [312]

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

← →
Sergey Masloff (2006-04-19 17:06) [314]

Игорь Шевченко © (19.04.06 16:18) [307]
>Если не трудно, приведи, плз, пример изменения стандарта ISO
А какой там код у страны "Сербия и Черногория" ?

to euru © (19.04.06 15:12) [303]:
>Вы предлагаете пользователю:
Понимаете, обычно пользователи работают со списками документов. Обычно на конкретную дату. Отсюда и стоит плясать. А если исходить из абстрактной задачи получения номера связанного документа по исходному, то решение будет получено не менее абстрактное.

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

>Упс. Минимизация JOIN-ов -- это не условие проектирования, а следствие
>использования естественных ключей.
Если будет нужно показать еще и автора операции, Вы его тоже в таблицу добавите вместе с ключом?

Игорь Шевченко © (19.04.06 15:23) [305]

> Я спрашивал про преимущества

Говоришь, работаешь на FB ?
Так расскажи о возможности создания PK или пользовательского индекса для 4-х полей varchar(32) в условиях национальной collation.
Это как раз из того примера выше, чтоя привел.

При использовании СК этой проблемы вообще не возникает, как правило.

← →
Sergey Masloff (2006-04-19 17:45) [317]

Jeer © (19.04.06 17:40) [316]
>Так расскажи о возможности создания PK или пользовательского индекса >для 4-х полей varchar(32) в условиях национальной collation.
Вроде пофиксили уже. Я что-то не слежу в последнее время но пробегало что толи в 1.5.2 толи в 2.0 раздвинули

Sergey Masloff (19.04.06 17:45) [317]

Да, с двойки и в yaffil, но до этого весь мир стоял и ждал ?

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

> Игорь Шевченко © (19.04.06 10:12) [258]
> xayam © (19.04.06 01:24) [257]
> Видишь ли, организация ISO не ставит своей целью сформировать
> именно твое представление.

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

> Объясни это говорящим на других языках. По крайней мере
> у тебя будет чем время занять.

Объяснять? Для этого просто добавляется поле с переводом на нужный язык

> Ничего не меняли. СССР было SU, Россия - RU. Никаких проблем
> для того, чтобы отличить, нету.

Отличить что? СССР вообще нет, это называется избыточность. И если они так меняют стандарты, то это как ком, он только больше и больше. А оно тебе надо?

> vuk © (19.04.06 17:37) [315]
> Понимаете, обычно пользователи работают со списками документов.
> Обычно на конкретную дату. Отсюда и стоит плясать. А если
> исходить из абстрактной задачи получения номера связанного
> документа по исходному, то решение будет получено не менее
> абстрактное.
Например, в нашей системе ежедневно генерируется 1000-2000 документов. Вы пользователю каждый раз открывать весь этот список и искать в нём нужный документ? Кроме того, конкретная дата может быть разной (сейчас мне понадобились текущие документы, через 5 мин -- недельной давности). Вы предлагаете держать по списку для каждой даты?

> См. выше. Обычно пользователи работают со списками документов.
> Обычно на конкретную дату.
Обычно пользователи работают с дебиторами/кредиторами или со счетами, и документы выбирают для них. А если они хотят посмотреть конкретный документ, то они просто вводят его номер и дату (списки для этого совершенно не нужны).

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

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