Первичный ключ GUID vs NUMBER в Oracle

← →
Ломброзо © (2006-10-26 12:43) [0]

Сабж. Интересуют мнения в разрезе производительность-удобство, если GUID хранить в виде CHAR(32)

← →
Reindeer Moss Eater © (2006-10-26 12:45) [1]

а почему тогда "vs Number" ?

← →
Курдль © (2006-10-26 12:46) [2]

> Первичный ключ GUID vs NUMBER в Oracle

Это смерти подобно! ЗАЧЕМ?!! Этим грешили только специалисты по MS SQL Server (не имея возможности получать ID автоинкрементных ключей до исполнения DML).

← →
Ломброзо © (2006-10-26 12:46) [3]

имеется в виду щщётчик по сиквенсу

← →
Игорь Шевченко © (2006-10-26 12:46) [4]

А смысл ?

← →
Курдль © (2006-10-26 12:50) [5]

> Ломброзо © (26.10.06 12:43)

Как ты оцениваешь индексирование по символьному "vs" целочисленному ключу?

← →
Reindeer Moss Eater © (2006-10-26 12:50) [6]

Производительнеее ROWID все равно ничего нет.
А ее можно привести к строке и обратно взад.

← →
Курдль © (2006-10-26 12:51) [7]

> Reindeer Moss Eater © (26.10.06 12:50) [6]
> Производительнеее ROWID все равно ничего нет.

ROWID не рекомендовано к использованию в досужих целях самим ораклом.

← →
Ломброзо © (2006-10-26 12:53) [8]

Игорь Шевченко © (26.10.06 12:46) [4]
1 Можно генерировать на клиенте или на аппсервере и знать значение ключа до момента вставки
2 Уникальная идентификация пакетов данных, передаваемых в офф-лайн режиме (например, SMTP-SOAP) между различными организациями, в которых установлена система
3 Апгрейд справочников от головной к дочерним организациям в том случае, если в дочерних организациях разрешено дополнять справочники своими записями
3 и т.д.

← →
Игорь Шевченко © (2006-10-26 12:57) [9]

Ломброзо © (26.10.06 12:53) [8]

> 1 Можно генерировать на клиенте или на аппсервере и знать
> значение ключа до момента вставки

И Number можно генерировать. Не вижу проблемы.

> 2 Уникальная идентификация пакетов данных, передаваемых
> в офф-лайн режиме (например, SMTP-SOAP) между различными
> организациями, в которых установлена система

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

> 3 Апгрейд справочников от головной к дочерним организациям
> в том случае, если в дочерних организациях разрешено дополнять
> справочники своими записями

Это неоднозначно. Точно также их можно upgradить и NUMBER"ом. Как конфликты будут определяться, если парочка дочерних организаций введеть одинаковые записи, отличающиеся только GUID"ом ?

← →
Курдль © (2006-10-26 13:00) [10]

> Ломброзо © (26.10.06 12:53) [8]
> Игорь Шевченко © (26.10.06 12:46) [4]
> 1 Можно генерировать на клиенте или на аппсервере и знать
> значение ключа до момента вставки

Вот этим-то оракл и отличается от MS SQL Server!!!
Делай запрос SEQ_NAME.NEXTVAL и получай гарантированно уникальное значение!
Более того, компоненты типа DOA и ODAC сами умеют это делать (им надо указать последовательность, "работающую" на выбранную таблицу).

← →
ANB © (2006-10-26 13:06) [11]

> (не имея возможности получать ID автоинкрементных ключей
> до исполнения DML)

А зачем его получать до ? Можно и сразу после. Я и в оракле так часто делаю - там returning есть.

Имхо : GUID - попытка полегче решить проблему репликации.
Плюс только один - быстро и легко во всех базах уникальные (с высокой вероятностью) ID-шники.
Минусы :
1) Вообще то вероятность хапнуть одинаковый ID ест, хоть и оооочень низкая
2) Генерится дольше сиквенса
3) Индексировать труднее - по числам индекс эффективнее
4) Нет мнемонической инфы, как то : источник формирования (номер сервера, например), порядок генерации (при грамотной организации формирования ID можно по номерам определить, какая из записей появилась позже)
5) Для намбера надо таки меньше места.
6) Мой учитель сказал, что по его опыту намберовые ID лучше (для меня это основной пункт :) )

← →
Игорь Шевченко © (2006-10-26 13:09) [12]

> 6) Мой учитель сказал, что по его опыту намберовые ID лучше
> (для меня это основной пункт :) )

Watch somebody used /debug once

(c) VMS user hierarchy

← →
Курдль © (2006-10-26 13:10) [13]

> ANB © (26.10.06 13:06) [11]
> А зачем его получать до ? Можно и сразу после. Я и в оракле
> так часто делаю - там returning есть.

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

← →
Desdechado © (2006-10-26 13:13) [14]

> 2 Уникальная идентификация пакетов данных, передаваемых
> в офф-лайн режиме (например, SMTP-SOAP) между различными
> организациями, в которых установлена система
Как это к ключам в БД имеет отношение?

И зачем тебе уникальный ключ на все виды таблиц?
Индексы по CHAR заметно тормознее.

ЗЫ каждому действию свой инструмент. GUID как PK в таблицах, имхо, не рулит.

← →
ANB © (2006-10-26 13:15) [15]

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

Это - а нафига ? Ну, если MS SQL такой кривой, что нету генераторов, кроме автоинкрементальных полей, то нафига все сразу формировать ?
Создаешь сначала мастер-запись. Потом вытаскиваешь ID и подставляешь в детали. И способ генерации в MS SQL тоже подкручивать можно.

В оракле можно сиквенсы подергать заранее и вставить. Хотя все равно операторы по одному поедут. А еще лучше по возможности запихать этот код в пакет и не мучится.

← →
ANB © (2006-10-26 13:17) [16]

Дополнб - т.к. MS SQL кушает пакеты DML операторов, то можно загонять полученные ID в серверные переменные (если я правильно их назвал) и далее их использовать. Тоже одним пакетом все и поедет.

← →
Курдль © (2006-10-26 13:20) [17]

> ANB © (26.10.06 13:15) [15]
> Это - а нафига ? Ну, если MS SQL такой кривой, что нету
> генераторов, кроме автоинкрементальных полей, то нафига
> все сразу формировать ?
> Создаешь сначала мастер-запись. Потом вытаскиваешь ID и
> подставляешь в детали.

Это шарашить обмен клиент-сервер при открытой транзакции?!!
На это я пойтить не могу :(

(Наверное поэтому не работаю с MS SQL).

← →
ANB © (2006-10-26 13:21) [18]

> Это шарашить обмен клиент-сервер при открытой транзакции?
> !!
> На это я пойтить не могу :(

А что тут такого неправильного ?

← →
Курдль © (2006-10-26 13:26) [19]

> ANB © (26.10.06 13:21) [18]
> > Это шарашить обмен клиент-сервер при открытой транзакции?
> А что тут такого неправильного ?

Т.е. как "что такого"?
Ты предлагаешь открыть транзакцию, запустить DML на сервер, дождаться исполнения, получить @@identity на сервере, отослать его на клиента, где заполнить нужные значения подчиненных таблиц, потом отправить новые DML на сервер и закрыть транзакцию?!!

MS SQL такого не простит!

← →
ANB © (2006-10-26 13:52) [20]

> Т.е. как "что такого"?
> Ты предлагаешь открыть транзакцию, запустить DML на сервер,
> дождаться исполнения, получить @@identity на сервере, отослать
> его на клиента, где заполнить нужные значения подчиненных
> таблиц, потом отправить новые DML на сервер и закрыть транзакцию?
> !!
>
> MS SQL такого не простит!

Во первых - простит
Во вторых - можно это все в одном пакете сделать.

← →
Курдль © (2006-10-26 14:13) [21]

> ANB © (26.10.06 13:52) [20]
> Во вторых - можно это все в одном пакете сделать.

Кто такой "пакет"?

← →
Ломброзо © (2006-10-26 14:14) [22]

А что, распределёнок никто не пишет? Поражает такое единодушие во мнениях. Я с трудом представляю себе жизнь без гуидов в системах, ну, к примеру, документооборота. Хотя его вполне можно использовать как вспомогательное поле, но в таком случае мы имеем фактически два первичных ключа

← →
Danilka © (2006-10-26 14:19) [23]

[8] Ломброзо © (26.10.06 12:53)
> 3 Апгрейд справочников от головной к дочерним организациям
> в том случае, если в дочерних организациях разрешено дополнять
> справочники своими записями

Как вариант, сиквенс приращение делает не на единицу, а, например, на тысячу.
А у каждой дочки - свой сдвиг.
То-есть, у одной ИД будут такие:
1000, 2000, 3000 ...
у второй дочки такие:
1001, 2001, 3001
и т.д.
в этом случае, ид не пересекутся.

← →
Reindeer Moss Eater © (2006-10-26 14:21) [24]

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

← →
Курдль © (2006-10-26 15:22) [25]

> Ломброзо © (26.10.06 14:14) [22]
> А что, распределёнок никто не пишет? Поражает такое единодушие
> во мнениях. Я с трудом представляю себе жизнь без гуидов
> в системах, ну, к примеру, документооборота.

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

← →
ANB © (2006-10-26 15:31) [26]

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

С трудом представляю - а на хрена он там нужен ? :)

> Кто такой "пакет"?

В MS SQL можно отправить на сервер несколько DML в одном запросе.
А можно и кусок T-SQL.
Фактически он каждый запрос понимает как что то вроде безымянного блока в оракле. При этом еще и можно вернуть набор данных. И не один.

← →
Ломброзо © (2006-10-26 15:39) [27]

Курдль © (26.10.06 15:22) [25]

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

← →
Курдль © (2006-10-26 15:42) [28]

> Ломброзо © (26.10.06 15:39) [27]

Не понимаю, какую там мочу надо слить с кровью... :)))
Я подозреваю, что GUID каким-то образом затыкает огрехи в проектировании БД.

Я кажется начал подозревать, что автор понимает под расперделенкой!
Это, видимо, ряд независимых систем со своими собственными БД, которые могут по необходимости совершать репликации либо друг с другом, либо с центром! Так?

> Совершенно верно, репликация - ключевое слово.

Интересно, как ты по гуиду потом определишь, на каком из серверов родилась запись ?
Я работал с системой, в которой в репликации было задействовано более 10 реальных серверов (не считая вспомогательных зеркал). И там нормально использовались именно намберовые ID. При этом при разборе полетов завсегда можно было проследить откуда что приехало.

> Ломброзо © (26.10.06 15:50) [32]
> Совершенно верно, репликация - ключевое слово.

А зачем вообще делать локальные базы? Клиенты не имеют гарантированного коннекта?

> ANB © (26.10.06 15:57) [33]
> При этом при разборе полетов завсегда можно было проследить
> откуда что приехало.

Я и говорю, что при правильном проектировании модели БД никакие GUID-ы не пригодились бы. Единственное условие - всем распределенным участникам "распределенки" выделить уникальный идентификатор (можно числовой :).

Ломброзо © (26.10.06 16:01) [34]

> По идентификатору организации. Тоже гуид. Причем берётся
> из Active Directory.

Тогда у тебя будет два GUID"а ? Один для уникальности записи, второй для организации, которая за эту запись ответственна ? Или я чего-то не понял...

> Ломброзо © (26.10.06 16:34) [37]
> Что в этом плохого? :)

Да, в принципе, ничего особенного. Из такой логики следует, что GUID-ным полезно сделать все первичные ключи всех таблиц всех БД в мире.
Пойми же, - ты так и не обосновал применение именно GUID для идентификации! В то время, как против него высказались очень многие.
Однако, надо отдать должное истине - базы с GUID-ными ID могут работать безошибочно...

У меня есть две системки на сотню тыс. записей в таблице max на гуидах. Работает как часы. Привык и руку набил. Просто планируется ещё один модуль, в котором есть мегатаблица, использующая декартово произведение, там дело может до десятка миллионов дойти.
Тест производительности на Oracle 10 XE я выполнить не смог :) миллион записей с идентификатором типа Number он вставлял минут 10, а над миллионом записей с идентификатором-char(32) оракл покряхтел полчаса и сказал, что у него интернал еррор.

> Ломброзо © (26.10.06 16:47) [39]
> У меня есть две системки на сотню тыс. записей в таблице
> max на гуидах. Работает как часы. Привык и руку набил.

Так у тебя реально не в одной таблице "GUID от безысходности" а такой стиль создания БД под оракл?
Попробуй "отбить" себе руку на место и спланируй следующий модкль, как дохтур Кайт прописал :)

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