Форум: "Базы";
Текущий архив: 2004.03.05;
Скачать: [xml.tar.bz2];
ВнизПоддержка 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]И...?
Страницы: 1 2 вся ветка
Форум: "Базы";
Текущий архив: 2004.03.05;
Скачать: [xml.tar.bz2];
Память: 0.54 MB
Время: 0.007 c