Dimitry Sibiryakov
SergSuper
Не, ну это моветон посылать читать документацию, вместо того чтобы парой
слов объяснить как такое в принципе возможно

Да ладно, теперь уже и без чтения понятно, что это особый "pre-defined"
тип данных повышенного размера с разведением по диапазону. Ничего нового
или интересного. С тем же успехом это мог бы быть и GUID...

Из интересного в данном случае то, что разведение по диапазоном штатно поддерживается СУБД и не требует каких либо трудозатрат по реализации. GUID действительно можно назвать заменой, но с моей точки зрения - плохой заменой, ибо он самый плохой кандидат для PK и FK с точки зрения индексирования и производительности.

Dimitry Sibiryakov
Из интересного в данном случае то, что разведение по диапазоном штатно
поддерживается СУБД и не требует каких либо трудозатрат по реализации.
За исключением выбора типа первичного ключа при проектировании БД. Или
оно может обычный Integer проальтерить в этот GLOBAL INCREMENT?
INCREMENT это не тип поля, а функциональность. INCREMENT в ASA может навешиваться на любое числовое поле - от tinyint до unsigned bigint. Поэтому при проектировании модели БД, если Вам известны максимальное кол-во записей для таблицы и оно не будет превышаться, Вы можете использовать любой подходящий целочисленный знаковый или беззнаковый тип для такой таблицы.

Dimitry SibiryakovУ Sybase всё так плохо с индексацией строк?
У компании Sybase ничего не может быть общего с индексацией строк, если какие то индексы и есть, то наверное котировок акций. У продуктов компании Sybase, то есть серверов ASA, ASE и IQ вполне все нормально с индексацией строк. Но если логически взглянуть на то, что такое индекс, как он хранится, производится балансировка, работает статистика и на основании какой информации оптимизатор принимает решение об использовании того или иного индекса, то становится ясным, почему индекс на базе числового поля с равномерными инкрементными значениями будет выгоднее GUID с хаотичными рандом значениями.

Дмитрий, нет типа GLOBAL INCREMENT. Скажите, чем для Вас отличаются следующие определения полей:
id unsigned bigint DEFAULT AUTOINCREMENT
id unsigned bigint DEFAULT GLOBAL AUTOINCREMENT
Изменить DEFAULT с обычного инкремента на глобальный через ALTER TABLE тоже не представляется сложным в рамках стандартного SQL. Вы ищите проблем там, где их нет.

Dimitry Sibiryakov
Возможно, но global increment не будет равномерным по определению: в нём
будут присутствовать сильно разнесённые (но при этом плотные) диапазоны
значений из всех БД. В то время как GUID даст более-менее равномерное
распределение на всём пространстве значений, что повысит селективность
индекса и ускорит его использование.

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

Я все таки не очень понял - чем Вас не устраивает решение, предложенное в ASA ? Тем что оно старое и работает - такие возражения не принимаются.

Dimitry Sibiryakov
ASCRUS
Я все таки не очень понял - чем Вас не устраивает решение, предложенное
в ASA ?

Меня не устраивает это решение? Почему Вы так думаете? Я просто пытаюсь
определить тип магии, применённой там для генерации уникальных значений
в распределённой БД. Понятно, что используется некий "идентификатор БД",
но откуда он берётся и каким способом укладывается в обычный целый тип
пока неясно. Оппоненты настаивают, что всё делается автоматически, а это
подозрительно, поскольку даже bigint не резиновый, а выяснять при
создании БД уже использованные "идентификаторы БД" серверу мешает связь
через FTP или e-mail.

В БД есть опция Global_DataBase_ID. Для консолидированной БД Вы ее устанавливаете в 0. Распределенные БД нумеруете по очереди дальше (или подгатавливаете распределенную БД с консолидированной штатными средствами ASA, которые сразу присваивают ей очередной код БД, создают БД, переносят в нее обьекты БД и все данные, которые по условиям репликации будут в области видимости распределенной БД). Теперь примеры по проектированию. У Вас есть таблица, которая изменяется только в центре и односторонне реплицируется в распределенные БД. Если данных в ней не планируется более 4 млрд. записей, то Вы обьявляете в ней тип unsigned int, ставите DEFAULT AUTOINCFREMENT, прописываете ее в публикации (в ASA штатно можно выполнить команду на консолидированной БД и она уйдет по реплике и выполнится на всех распределенных БД, так что звонить и просить всем в БД писать таблицу в публикацию или писать дополнительный код для этого не придется). Все как обычно с инкрементами. Далее у Вас есть таблица, в которой в консолидированной БД в итоге может быть более 4 млрд записей, она будет участвовать в двусторонней репликации, где планируется, что в каждой распределенной БД свой интервал записей не превысит 1 млрд записей. Тогда Вы обьявляете в ней тип unsigned bigint, пишите DEFAULT GLOBAL AUTOINCREMENT (1000000000), так же включаете ее в реплику. Теперь у Вас записи, введенные в консолидированной БД в эту таблицу, начнут нумероваться с 1, для распределенной базы 1 начнут нумероваться с 1000000001 и так для каждой базы далее, поэтому при сливе записей в консолидированную БД наложений PK или UK не будет. Но что же делать, если все таки какая то распределенная БД достигнет предела своей нумерации ? ASA так же предлагает штатно решить эту проблему - пишите событие (EVENT) на внутренней системное событие RemainingValues, в котором или присваиваете новый код БД или отсылаете письмо администратору с уведомлением, если не хотите делать автоматом. Теперь вопрос - что будет для консолидированной БД, если распределенная БД изменит свой код и начнет генерить ключи в новом диапазоне ? Ответ - да ничего не будет, репликация будет продолжать работать, так как уникальность соблюдается, логика тоже будет работать, так как глобальные инкременты и код БД - это просто штатный функционал и на бизнес логику он никакого отношения не влияет. Логика распределения данных должна уже быть спроектирована самим архитектором БД - если БД на самом деле одна, просто есть удаленные или мобильные офисы, которые не могут с ней работать из за плохих или периодических каналов связи - то достаточно просто навесить на таблицы БД двустороннюю репликацию. Если в наличии удаленные подразделения (филиалы), значит будет справочник подразделений, в таблицах будет стоять поле КодПодразделения, в реплике на таблицы, данные которых имеют область видимости по подразделениям будет стоять определение области видимости в публикации по полю КодПодразделения, а для подписок распределенных БД указано значение КодПодразделения. Таким образом, если в распределенной БД вводится запись, она попадает в консолидированную БД, если в консолидированной БД добавить запись с кодом подразделения, на которую крутиться распределенная БД, то эта запись так же в итоге добавится в распределенную БД этого подразделения, но не появится в прочих распределенных БД, имеющих другой код подразделения. Все это позволяет строить многоуровневые схемы репликации, разбивая потоки реплицируемых данных по нужной логике, где можно запросто поднять консолидированную БД, на нее навесить 2 распределенных БД с разной областью видимости, на каждую из них навесить еще по 2 распределенных БД, у которых будет одинаковая область видимости и т.д. и т.п.

Все управление данным хозяйством реализовано штатным DDL и функциями (например для инкрементов и глобальных инкрементов есть функция, которая возвращает новое значение для указанной таблицы и является аналогом сиквенсеров). Сервер репликации так же управляется прямо из SQL. Для каждой из распределенной БД сервер репликации может использовать доставку из 3 способов передачи информации - файлами через зашаренный ресурс, email или ftp. Все это организуется автоматически и сервер репликации сам с лога БД считывает изменения, определяет куда они реплицируются, нарезает файлы с информацией, кладет их по нужному протоколу, забирает ответные файлы от второй стороны, и применяет их на БД. В случае ошибок (не хватает файлов, не сошлось CRC и т.д.), он тем же способом генерит запросы к второй стороне (просьба переслать повторно, необходима информация начиная с такого то места и т.д.).

P.S. Я лично из виденного считаю репликацию ASA лучшей в реализации, именно из за того, что она штатно и гармонично составляет единое целое с самим сервером, поэтому достигается такая легкость в проектировании, настройке и управлении ею. Any questions ?