Поддержка GUID в InterBase/FireBird

← →
VLAD-MAL (2004-02-09 14:16) [0]

Оч. хочу для первичных ключей юзать GUID. (Ну, типа, меньше гемора с генераторами/триггерами (мелочь, конечно); а самое главное - вопросы с репликацией проще решаются...)
Для реализации фантазии хватает на тестовое поле (32символа) или на составной ключ из 2х BIGINT. Первое - как - то уж больно громоздко по объему, второе - несколько громоздко по реализации.

Кто-нибудь идет в этом направлении, или я один такой единственный и неповторимый (тупой и упрямый)?

Вообще, для IB/FB планируется ли введение такого типа данных (в MS SQL есть!) ?

Подскажите?????

← →
Digitman (2004-02-09 14:25) [1]

> хочу для первичных ключей юзать GUID

юзай. никто и ничто не мешает.
как будешь хранить его, индексировать и делать выборки по нему - все зависит от фантазии
а получить GUID оч просто : реализуй и подключи UDF, в которой будешь вызывать ф-цию СoСreateGUID() и возвращать полученный GUID в вызывающую SP/тиггер любым удобным тебе докум.способом

← →
Digitman (2004-02-09 14:32) [2]

хранить GUID-данные, очевидно, на сей момент лучше всего в домене типа varchar(16) :

CREATE DOMAIN GUID AS
VARCHAR(16) CHARACTER SET OCTETS
COLLATE OCTETS

поля такого типа позволяют хранить послед-ть байтов с любыми значениями (экв-но array[0..15] of byte) и могут быть индексированы обычным образом со всеми вытекающими ...

← →
asp (2004-02-09 14:35) [3]

IMHO хранение лучше осуществлять в CHARACTER(32). Для СУБД менее накладно.

← →
Anatoly Podgoretsky (2004-02-09 14:42) [4]

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

← →
VLAD-MAL (2004-02-09 14:43) [5]

2 Digitman © (09.02.04 14:25) [1]
а получить GUID оч просто : реализуй и подключи UDF, в которой будешь вызывать ф-цию СoСreateGUID() и возвращать полученный GUID в вызывающую SP/тиггер любым удобным тебе докум.способом
- мне как-то удобнее по логике id на клиенте генерить, уже устоявшиуся метод работы (ну, типа компактный рефреш/ создание сложных структур мастер/деталь при кешировании записи и т.п.).

2Digitman © (09.02.04 14:32) [2]
CREATE DOMAIN GUID AS
VARCHAR(16) CHARACTER SET OCTETS
COLLATE OCTETS

Класс! Век живи, век учись! Спасибо!

2 asp © (09.02.04 14:35) [3]
IMHO хранение лучше осуществлять в CHARACTER(32). Для СУБД менее накладно.

А в чем проблема/накладность, если не секрет?

← →
Digitman (2004-02-09 14:50) [6]

> VLAD-MAL (09.02.04 14:43) [5]

> мне как-то удобнее по логике id на клиенте генерить

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

лучше это делать централизовано, на серв.стороне, в триггере, и сгенерированное значение уже возвращать клиенту

или (для целей репликации) совместить оба варианта :

IF (new.GUID_field is NULL) then
new.GUID_field = UDF_GetNewGUID;

т.е. если клиент сам не сгенерировал GUID, то это сделает сам сервер в соотв.триггере в вышеприведенном коде

← →
Digitman (2004-02-09 14:53) [7]

> asp © (09.02.04 14:35) [3]

на кой ляд 32-то ? длина GUIDа - 16 байт

← →
VLAD-MAL (2004-02-09 14:53) [8]

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

лучше это делать централизовано, на серв.стороне, в триггере, и сгенерированное значение уже возвращать клиенту

Смешно даже, ради чего же я GUID завожу? Тогда бы меня генераторы вполне бы устроили.
А неуникальность перв. ключа - это как? И что, сервак такие вещи потерпит?

← →
Anatoly Podgoretsky (2004-02-09 14:58) [9]

Digitman © (09.02.04 14:50) [6]
Вероятно равна нулю, ну почти нулю 2^128 степени

← →
VLAD-MAL (2004-02-09 14:59) [10]

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

← →
asp (2004-02-09 15:00) [11]

VARCHAR - строка переменной длины. Это, разумеется, в большинстве случаев удобнее и храниться символов столько, сколько заполнено. Но СУБД при чтении "вынуждена оценивать" длину строки.
В случае CHARACTER СУБД читает количество символов определенных при объявлении столбца таблицы.
Поскольку GUID всегда одинаковой длины - логичнее объявить CHARACTER().

← →
VLAD-MAL (2004-02-09 15:04) [12]

2 asp © (09.02.04 15:00) [11]

Понял, я думал - Вы по поводу длины

... VARCHAR(16) CHARACTER SET OCTETS
COLLATE OCTETS

vs

... CHARACTER(32)

То есть Вы не против варианта:

... CHARACTER (16) CHARACTER SET OCTETS
COLLATE OCTETS

???

А FIB+/IBX/BDE - компоненты позволяют в .AsString все подряд записывать?

← →
asp (2004-02-09 15:07) [13]

Не против :)

← →
VLAD-MAL (2004-02-09 15:08) [14]

Спасибище, монстры SQL и Delphi!

← →
Digitman (2004-02-09 15:10) [15]

> Смешно даже, ради чего же я GUID завожу?

да фиг тебя знает - зачем)

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

> Тогда бы меня генераторы вполне бы устроили

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

> неуникальность перв. ключа - это как?

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

И что, сервак такие вещи потерпит?

нет, конечно ...

← →
VLAD-MAL (2004-02-09 15:14) [16]

да фиг тебя знает - зачем)
1. Ну, DigitMan, вопрос срывается в сторону "а нафиг это надо..."
Ну, в лом мне заниматься такими вещами, как распределять диапазоны значений для первичных ключей между филиалами клиентов и их ноутбуками клиентов "на выезде". GUID придумали ж, что же не юзать?

2. FIB+ кто-нибудь юзал в пакете с "CHARACTER SET OCTETS COLLATE OCTETS" ?

← →
Anatoly Podgoretsky (2004-02-09 15:19) [17]

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

← →
VLAD-MAL (2004-02-09 15:25) [18]

Вроде как о клиент-сервере идет речь

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

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

← →
Digitman (2004-02-09 15:28) [19]

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

а зачем это вообще нужно ?

> GUID придумали ж, что же не юзать

любопытно, как это сочетается с "распределять диапазоны значений"

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

← →
VLAD-MAL (2004-02-09 15:31) [20]

Да я не об этом, я об Вашем предложении использовании Field Type Int64 + generator"s.

← →
Anatoly Podgoretsky (2004-02-09 15:32) [21]

VLAD-MAL (09.02.04 15:25) [18]
Нужен прихнак операции - добавление/изменение, но врядли ты когда либо увидишь совпадение, тем более, что из твоих слов выходит, что сеть есть.

← →
VLAD-MAL (2004-02-09 15:34) [22]

2 Anatoly Podgoretsky © (09.02.04 15:32) [21]

Да-да, спасибо, эти подробности мне известны...

← →
Digitman (2004-02-09 15:35) [23]

> VLAD-MAL (09.02.04 15:31) [20]

так и я о том же) ... мне только непонятно, на кой шут какие-то там диапазоны нужны ?

← →
roottim (2004-02-09 15:36) [24]

> [6]... что т я всегда думал, что гуид сформированный на разных ПК с сетевыми картами гарантированно уникален по соображению уникальности серйного номера сетевой карты..
по крайней мере они об этом говорят

← →
VLAD-MAL (2004-02-09 15:39) [25]

О, DigitMan, как Вы мне помогли (CHARACTER SET OCTETS...) , и не знаете, зачем диапазоны нужны...
Ну, это один из вариантов схемы репликации - когда каждому юзеру, владеющему экземпляром/фрагментом задается диапазон, начиная с которого у него генерится значение ключа (искуственного, автоинкрементного). GUID здесь не причем.

Спасибо!

← →
VLAD-MAL (2004-02-09 15:39) [26]

2 roottim (09.02.04 15:36) [24]

Да.

← →
Digitman (2004-02-09 15:43) [27]

> и не знаете, зачем диапазоны нужны

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

← →
VLAD-MAL (2004-02-09 15:46) [28]

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

Как????
Скажи, я тебя пивом поить буду до конца недели!

У меня же клиенты с длительным отключением!

← →
Digitman (2004-02-09 15:47) [29]

тем более что запаса сквозного диапазона при использовании QWORD-счетчика - выше крыши ! век его не исчерпаешь ни при каких , даже самых "замороченных" репликациях

← →
Anatoly Podgoretsky (2004-02-09 15:49) [30]

roottim (09.02.04 15:36) [24]
Ни как нет, после того как будет выдано 2^128 будет гарантированое повторение. Гарантированная уникальность требует неограниченной длины последовательности. Это простая математическая теория.

← →
VLAD-MAL (2004-02-09 15:52) [31]

Ни как нет, после того как будет выдано 2^128 будет гарантированое повторение.
Ну, к этому времени я успею добежать до канадской границы.

← →
Digitman (2004-02-09 15:53) [32]

> Как????

ты TClientDataset используешь ?

← →
VLAD-MAL (2004-02-09 15:54) [33]

Бывает.

← →
Anatoly Podgoretsky (2004-02-09 15:58) [34]

VLAD-MAL (09.02.04 15:52) [31]
Это было не к тебе, а к самоуверенному замечанию "гарантированно уникален". Любой человек немного знакомый с математикой понимает, что это не так.
А для тебя я сказал, что ты успеешь добежать до канадской границы даже при отсутствии сетевой карты.

← →
VLAD-MAL (2004-02-09 15:59) [35]

"Сетевая карта" - это типа карта Канады?

← →
VLAD-MAL (2004-02-09 16:02) [36]

Ну, Digitman-чик ( © (09.02.04 15:53) [32]) , ну, подскажи, как?

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

← →
Digitman (2004-02-09 16:21) [37]

> VLAD-MAL (09.02.04 16:02) [36]

у TClientDataSet для этой цели есть замечательный метод ApplyUpdates()

ты вникал в суть и логику его использования/работы ?

← →
VLAD-MAL (2004-02-09 16:30) [38]

Что-то мы о разных вещах говорим...
Ты о кэшировании записи, я - о репликации...

Ну, и какая будет логика работы:
- имеется база данных, ~ 50 таблиц, как ни странно, связанных между собой;
- основная масса клиентов юзает в реал-тайме, по локалке, проблем нет;
- приезжает тетка из Воронежа, скачивает себе на ноут копию базы, и уезжает к себе в деревню... На неделю.
- эта зараза возвращается, в ее базе новые позиции прайса, новые клиенты, появились новые документы на основе новых позиций. Да, некоторые документы - на основании "старых" позиций.
- за время ее отсутствия у нас тоже ко-что изменилось.

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

Да, я использую иногда TClientDataSet. И при чем тут моя проблема?

← →
Digitman (2004-02-09 16:34) [39]

проблема - в неиспользовании (или неэффективном использовании) механизма delta-набора данных, формируемых этим компонентом

← →
VLAD-MAL (2004-02-09 16:36) [40]

И...?

← →
Digitman (2004-02-09 16:44) [41]

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

← →
VLAD-MAL (2004-02-09 16:53) [42]

Уважаемый, мне запихнуть запись любой ценой на сервак не главное - мне главное, чтобы id записи, которую сгенерил клиент, ГАРАНТИРОВАННО отличался от id записей, сгенерированных другими "локальными" и другими "надолго удаленными" клиентами.
Пример: тетка из Воронежа добавила новую позицию прайса "Воронежские котлеты", а потом сгенерила счет, позиция которого ссылается на эту позицию счета. В это время другой клиент в "основной" базе сгенерил другую позицию прайса "Саратовские гармошки" с тем же id. Как при переносе счета узнать, что эти позиции счета ссылаются, если их id вполне корректен?

← →
Digitman (2004-02-09 16:59) [43]

> VLAD-MAL (09.02.04 16:53) [42]

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

← →
VLAD-MAL (2004-02-09 17:05) [44]

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

Ну, ладно, похоже, разговор слепого с глухим.

Спасиба. Удачи.

← →
Digitman (2004-02-09 17:12) [45]

по-русски, на огурцах :

я подключился к серверу и говорю, мол, добавь в такую-то таблицу такую-то запись с перв.ключем = 100

сервер мне сообщает в OnReconcileError(), мол, такой перв.ключ записи уже существует

я тут же запрашиваю у сервера "свежий" GEN_ID, повторяю реконсайл, сервер "проглатывает"

замечательно ! у всех связанных таблиц в моей базе я в нужной послед-ти меняю ключ на "свежий"

аналогично - для модифицируемых записей

← →
y-soft (2004-02-10 08:19) [46]

По поводу использования GUID в IB - классическая статья Дмитрия Кузьменко: http://www.ibase.ru/devinfo/test2.htm

← →
roottim (2004-02-10 08:20) [47]

>Anatoly Podgoretsky © (09.02.04 15:58) [34]
причем тут 2^128? -> данное высказывание касается одной машины... действительно, генерация ключа на одной машине с сетевой картой происходит с н-ой долей вероятности получить такой-же
я же сказал только то что читал об этом..
генерация гуид на основе сетевой карты дает гарантию не получить такой-же на другой машине с сетевой картой...
(то-есть речь идет в контексте 2 ПК с разными сетевыми) по причине уникальности сер.номера сетевой карты...
> Любой человек немного знакомый с математикой понимает, что это не так
ну физмат то я заканчивал...
вы может считайте что генерация пойдет с 0, что позволит дать вашу колизию... ну а я думаю иначе...

← →
Digitman (2004-02-10 08:41) [48]

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

100%-ю гарантию может дать только господь бог)

в этом же случае речь идет лишь о весьма значительном уменьшении вероятности генерации одного и того же значения на разных машинах

← →
roottim (2004-02-10 11:21) [49]

> Digitman © (10.02.04 08:41) [48]

ну если быть математически :) точным вероятность сведется к вероятности появления 2-х сетевых с одинаковыми серийниками.

к чему все это.. смысл [24] то был по высказыванию [6] о том что
> мне как-то удобнее по логике id на клиенте генерить
>>не есть это хорошо, вероятность получения граблями по неуникальности перв.ключа повышается

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

← →
ZrenBy (2004-02-10 11:34) [50]

Тайна GUID :)

http://www.sql.ru/forum/actualthread.aspx?bid=1&tid=22258

Поддержка GUID в InterBase/FireBird Найти похожие ветки