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