zenk
Допустим, есть головная контора и филиалы.
Везде стоят базы одинаковой структуры, ссылочная целостность базируется на PRIMARY KEYS по полям SERIAL.
Как в головной организации создать объединённую базу по всем филиалам?
У кого есть опыт?
Смотря что потом с этой объединенной информацией делать...
Если каналы связи хорошие, то для выполнения консолидированных отчетов можно использовать распределенные запросы.
Если хочется (или нужно) иметь всю информацию (копию) в одном месте , то встанет вопрос ее актуальности - тогда можно использовать однонаправленную репликацию нужных таблиц. Можно собрать физически все БД в одном месте (на одном сервере), но так и не объединять в одну БД, просто каждая БД будет иметь свое название и тогда даже структуру таблиц менять не надо.
Если же нужно слить всю информацию в одну центральную БД, то без тщательного перепроектирования не обойтись.
Есть еще вопросы общих справочников (можно ли их корректировать на местах или только в центре), целостности и актуальности информации, уникальных идентификаторов по всей системе, привязки к филиалам и мн.др.

zenk авторЕсли каналы связи хорошие, то для выполнения консолидированных отчетов можно использовать распределенные запросы.

Это как?
Как это должно обрабатываться на клиенте?
Допустим, хотим получить список договоров по всем филиалам?
Динамически строить SELECT ... UNION SELECT по 10-20 серверам?
Боюсь, даже теоретически время отклика будет зашкаливать за рамки комфортной работы.

1. Повторюсь - "Если каналы связи хорошие"
2. "для выполнения консолидированных отчетов" - т.е. это не оперативная "комфортная" работа, а аналитика или отчетность , а время реакции для этих запросов играет значительно меньшую роль, главное актуальность и полнота.
3. + Не надо заморачиваться с репликами и копированием баз
4. + Полная "свобода на местах" в части ведения справочников и остального :)
5. Если это раз в месяц, то выполняясь по ночам, время выполнения запросов вообще мало значимо.

zenk авторЕсли хочется (или нужно) иметь всю информацию (копию) в одном месте , то встанет вопрос ее актуальности - тогда можно использовать однонаправленную репликацию нужных таблиц. Можно собрать физически все БД в одном месте (на одном сервере), но так и не объединять в одну БД, просто каждая БД будет иметь свое название и тогда даже структуру таблиц менять не надо.
Филиальские базы нужны для построения консолидированной отчётности раз в месяц, ну и для получения прочей информации.
Таким образом, on-line доступа к филиалам нам не требуется.

Зачем тогда вопросы выше ? О получении списка договоров на клиенте ?
zenkВ крайнем случае - ежедневные ночные выгрузки.
Когда объем каждой БД станет по несколько гиг, тогда я посмотрю на эти "ночные выгрузки" с 10-20 серверов...
zenkМожно вопрос: какие версии Informix нужны для репликации - 1 Ent+ n ODS или (n+1) Ent?

zenkНеобъединённые базы на одном сервере - большая проблема для клиента БД.

zenk авторЕсли же нужно слить всю информацию в одну центральную БД, то без тщательного перепроектирования не обойтись.
Есть еще вопросы общих справочников (можно ли их корректировать на местах или только в центре), целостности и актуальности информации, уникальных идентификаторов по всей системе, привязки к филиалам и мн.др.

Проблема справочников решается организационно - редактирование части таблиц на филиалах будет запрещено. Если окажется, что филиалам нужно будет редактировать справочники (только добавлять записи), переведём справочники на Sequence с minvalue. Случай UPDATE для записей из центральной базы не рассматриваем, IMHO, это допускать нельзя.

А вот про перепроектирование базы не расскажите? Именно этот вопрос интересует больше всего. Какие цели надо поставить при этом?

Не закончил ответ в предыдущий раз - случайно нажал Enter и сообщение тут же публикуется :(
zenkМожно вопрос: какие версии Informix нужны для репликации - 1 Ent+ n ODS или (n+1) Ent?
Проще всего посмотреть в документации - там все тщательно расписано. К тому же есть разные виды репликации, к тому же, я не знаю, какая версия у тебя...
zenkНеобъединённые базы на одном сервере - большая проблема для клиента БД.
А зачем стандартному клиенту работать со всеми базами ? Это явно отдельный клиент и сложностей там никаких не вижу - справочник филиалов прямо завязывается на перечень БД и т.д.

zenk
А вот про перепроектирование базы не расскажите? Именно этот вопрос интересует больше всего. Какие цели надо поставить при этом?
Нет, не расскажу - это не маленький вопрос, к тому я не специалист в этой области. Главное - четко понимать, что вы хотите от системы в реальных условиях и не заморачиваться "на красоту". И еще один совет из жизни - "преодолевайте проблемы по мере их появления" :)

zenkЕсли каналы хорошие, то можно и терминальный доступ организовать. К тому же даже скоростные каналы на длинных дистанциях не позволяют получить малое время реакции.
Что, электроны на 100км "долго бегут" ? Что то я не понял "скоростные каналы на длинных дистанциях" :) В чем же тогда измеряется "скорость канала" ? Ведь это и есть пропускная способность в единицу времени (которая меряется по самому плохому сегменту) и от расстояния уж никак не зависит...

zenk[quot ]4. + Полная "свобода на местах" в части ведения справочников и остального :)
Нет, так нельзя. Как я буду строить отчёт по типу договора, если на каждом филиале справочник типов договоров будет разным?
Я , вообще то, и в кавычки брал и смайлик в конце ставил....
А ты мне рассказываешь, что так нельзя.
zenk 5. Если это раз в месяц, то выполняясь по ночам, время выполнения запросов вообще мало значимо.
Нет, ночью будем данные забирать. А отчёты будем днём строить, когда люди работают.
А что мешает в пакетном режиме строить ежемесячные отчеты ?
Много интеллекта надо, чтобы выбрать форму и дату отчета ?
Ну, это я так, в сторону :)
zenkЗачем тогда вопросы выше ? О получении списка договоров на клиенте ?
Не понял, а как без договоров отчёты по ним строить?

Я о другом, если не нужна оперативная и распределенная обработка транзакций, то зачем тогда спрашивать о виде селекта...
[quot zenk]
Необязательно скачивать dbexport или onunload. Можно скачивать только те записи, которые изменились со времени предыдущей закачки (на все таблицы ведутся логи).
К тому же можно заранее проконтролировать наличие баз.
Если ты начнешь "изобретать велосипед", т.е. строить свою систему репликации, то я тебе не завидую - там очень много подводных камней, о которых ты еще и не задумывался (на вскидку - в филиале упал сервер и восстановили по состоянию на сутки назад, а пропавшая информация уже ушла наверх...).
А другие уже подумали и сделали. Поэтому, если уж и использовать репликацию, то родную информиксовскую, которая позволяет тиражировать срезы таблиц и построена не на "тяжелых" триггерах.
zenk
Что делать, если при формировании "самого срочного и важного отчёта" прервётся связь с одним из филиалов?
А это вопрос к чему или к кому ? Я тебя вовсе не убеждаю использовать распределенные запросы или реплики или копировать БД. В каждом из способов много нюансов и сложностей и все зависит от твоих целей и задач.
А также способности все продумать и решить возникшие проблемы.

zenk[quot ]А зачем стандартному клиенту работать со всеми базами ? Это явно отдельный клиент и сложностей там никаких не вижу - справочник филиалов прямо завязывается на перечень БД и т.д.
Так стандартный клиент это всё уже умеет (по одной базе). А так что получается - сделали отдельного клиента для отчётов, а через месяц некоторые цифры в отчёте удивили, захотели узнать, что это за договор такой интересный, придётся дописывать просмотр параметров договора. Постепенно в клиент для отчётов возвратится вся функциональность по просмотру данных из стандартного.
Ну так сделайте наоборот - добавьте в стандартный клиент необходимую дополнительную функциональность для работы с многими базами, которая добавляется только нужным людям. Не пойму, в чем проблема.

авторНет, не расскажу - это не маленький вопрос, к тому я не специалист в этой области. Главное - четко понимать, что вы хотите от системы в реальных условиях и не заморачиваться "на красоту". И еще один совет из жизни - "преодолевайте проблемы по мере их появления" :)
Спасибо. Хотелось поучиться на чужих ошибках :-)
У меня впечатление, что ты себе систему некую уже придумал, а получив другой совет, возражаешь :)