Поддержка 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]

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

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

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

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

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

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

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

> Как????

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

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

Бывает.

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]) , ну, подскажи, как?

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

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

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

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

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

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

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

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

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

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

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

И...?

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