Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Поддержка GUID в InterBase/FireBird [D7, FireBird 1.5 RC8]

Страницы: < 1 2 3
VLAD-MAL © (2004-02-09 14:16:00)

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

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

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

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

VLAD-MAL (2004-02-09 14:59:00) [41]

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

Anatoly Podgoretsky (2004-02-09 14:58:00) [42]

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

VLAD-MAL (2004-02-09 14:53:00) [43]

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

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

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

Digitman (2004-02-09 14:53:00) [44]

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

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

Digitman (2004-02-09 14:50:00) [45]

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

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

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

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

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

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

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

VLAD-MAL (2004-02-09 14:43:00) [46]

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). Для СУБД менее накладно.

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

Anatoly Podgoretsky (2004-02-09 14:42:00) [47]

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

asp (2004-02-09 14:35:00) [48]

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

Digitman (2004-02-09 14:32:00) [49]

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

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

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

Digitman (2004-02-09 14:25:00) [50]

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

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

Страницы: < 1 2 3

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »