Репликация БД и глобальный поиск

← →
ZevSS © (2007-04-12 17:07) [0]

Имеется БД на MS SQL Server 2000 по учету персонала организации. Структуру пока не привожу.
1. Организация имеет филиалы по области. В каждом филиале ведется своя база данных (т.е. в каждом филиале установлен свой MS SQL Server). В центральном офисе должна скапливаться общая база данных. Как обеспечить сбор данных со всех филиалов в центральный офис? Сети нет. Т.е. надо в филиале сделать выгрузку БД на CD, а в центральном офисе присоединить эту БД к общей базе. Причем, такой перенос должен быть раз в неделю, т.е. данные должны обновляться, а не дублироваться? Как такое осуществить?
2. Как сделать глобальный поиск по всем полям в БД? Причем некоторые поля могут быть не заполнены пользователем, а некоторые могут иметь несколько значений?

← →
Val © (2007-04-12 17:16) [1]

1.структуры баз идентичны? справочники унифицированы?
2. можно подробнее о смысле затеи?

← →
stone © (2007-04-12 17:17) [2]

> 1.

Изучай bcp (Bulk Copy Programm) идет в составет MS SQL Server 2000, собственно любые снапшуты через нее и делаются.

> 2

Ни фига не понял.

← →
StriderMan © (2007-04-12 17:42) [3]

> 2. Как сделать глобальный поиск по всем полям в БД? Причем
> некоторые поля могут быть не заполнены пользователем, а
> некоторые могут иметь несколько значений?

это жесть. А типы данных в полях все одинаковые что ли?

получить из системной таблицы список таблиц, для каждой получить список полей, построить запрос, выполнить.

← →
ZevSS © (2007-04-12 17:50) [4]

> 1.структуры баз идентичны? справочники унифицированы?

Да. Все один к одному.

> 2. можно подробнее о смысле затеи?

В БД есть несколько таблиц, содержащих информацию о сотрудниках организации. Главная таблица tdSotr содержит ФИО и GUID. Все остальные подчиненные - связаны с главной по GUID - содержат, например, послужной список сотрудника (tdWork), данные о поощрениях и т.д. Каждая таблица, естественно, содержит от 10 полей.
К примеру, пользователь захотел найти всех сотрудников, которые (уволены) and (имели награды) and (родились в 1972 году). Как конструировать SQL-запрос по любому количеству полей из всех таблиц БД? Трудно так на словах объяснить. Грубо говоря нужен Конструктор запросов.

← →
Jan1 (2007-04-12 17:54) [5]

Offline replication
1. Или писать самому - что влечет за собой гемор, но кучу интересного :)
Если в БД все ПК - гуиды, то просто, если int - то сложнее.
2. Купить.
Передавать можно хоть по почте, хоть на дискетах, хоть на собаках...

← →
Sergey13 © (2007-04-13 08:41) [6]

> [4] ZevSS © (12.04.07 17:50)
> Как конструировать SQL-запрос по любому количеству полей из всех таблиц БД?
Вот так сидеть и конструировать. Как еще то? Иногда возможно написать универсальный запрос и включать его "ветки" через параметры. Иногда получается только динамически строить его в клиенте.

← →
Jan1 (2007-04-13 09:47) [7]

> ZevSS ©

Если надумаешь писать сам, то могу посодействовать. Сам писал под МС и ФБ. Можем тут развести топик на пару тыс. постов. И люди покритикуют и народ подучится.

← →
ZevSS © (2007-04-15 11:47) [8]

> Если надумаешь писать сам, то могу посодействовать. Сам
> писал под МС и ФБ. Можем тут развести топик на пару тыс.
> постов. И люди покритикуют и народ подучится.

Поиск, естественно, буду писать сам. А вот по поводу первого вопроса я думаю, что может лучше использовать экспорт\импорт через XML ? Как такой вариант? Или есть варианты проще?

← →
Jan1 (2007-04-16 09:05) [9]

> А вот по поводу первого вопроса я думаю, что может лучше
> использовать экспорт\импорт через XML ? Как такой вариант?
> Или есть варианты проще?

Это одна из частей репликации - а именно траспорт. Его хоть на собаках сделай.
Тебе надо будет решить много(!) других вопросов: как ты будешь логировать даннные, как ты будешь решать конфликты, как ты будешь расширять свою систему и т.п. и т.д

← →
ZevSS © (2007-04-16 20:12) [10]

> Это одна из частей репликации - а именно траспорт. Его хоть
> на собаках сделай.
> Тебе надо будет решить много(!) других вопросов: как ты
> будешь логировать даннные, как ты будешь решать конфликты,
> как ты будешь расширять свою систему и т.п. и т.д

А готовых компонентов для этого не существует ? У меня, в принципе идея выгрузки\загрузки такая:
1. Создаем запрос в ADOQuery, который объединяет данные всех таблиц, которые должны присутствовать в выгрузке (используем JOIN)
2. Результат запроса экспортируем в XML-файл
3. Полученный XML-файл копируется на другой комп (где должна храниться общая БД) и производится его импорт в БД.
При импорте только нужно учесть, что в БД есть автоинкрементальные поля и номера GUID могут совпадать.
p.s. на данном этапе важнее сделать выгрузку\загрузку, а потом уже глобальный поиск.

← →
Jan1 (2007-04-16 20:19) [11]

> А готовых компонентов для этого не существует ?

Для репликации? :) нет и быть не может. Это большая задача, которую нет смысла лепить в компоненты.

> 1. Создаем запрос в ADOQuery, который объединяет данные
> всех таблиц, которые должны присутствовать в выгрузке (используем
> JOIN)

Какие именно данные надо выгрузить? Все? Или часть? Этим занимается логирование.

> 3. Полученный XML-файл копируется на другой комп (где должна
> храниться общая БД) и производится его импорт в БД.
> При импорте только нужно учесть, что в БД есть автоинкрементальные
> поля и номера GUID могут совпадать.

Вот тут и начинается самое интересное: конфликты, тех записей которые менялись на разных точках, конфликты удаления и т.п. Это отдельный большущий вопрос.

> а потом уже глобальный поиск.

Кстати, глобальный поиск это чего? поиск чего-то такого, что и сам не знаю? А смысл?

← →
ZevSS © (2007-04-22 16:03) [12]

> Какие именно данные надо выгрузить? Все? Или часть? Этим
> занимается логирование.

Ставлю вопрос конкретно: Как мне выгрузить результат SQL-запроса в XML файл на диск? Как в последствии работать с этим файлом, как с внешней таблицей? Я буду сам анализировать все поля в БД и в XML и на основании анализа делать выгрузку\загрузку.

← →
Jan1 (2007-04-23 08:47) [13]

> Ставлю вопрос конкретно: Как мне выгрузить результат SQL-
> запроса в XML файл на диск? Как в последствии работать с
> этим файлом, как с внешней таблицей? Я буду сам анализировать
> все поля в БД и в XML и на основании анализа делать выгрузку\загрузку.
>

читай хелп по ADO. SaveToFile и LoadFromFile - тебе помогут. Но ИМХО, ты :
1. Выбрал не тот формат данных для обмена. Уж больно он нептимальный.
2. Начал не с того. Выгрузит и передать - это малюсенькая задача.
Тебе ой как много еще прийдется попотеть, чтобы пользователи тебя перестали бить, когда ты затрешь то что они делали пару недель...

← →
ZevSS © (2007-04-24 00:21) [14]

> читай хелп по ADO. SaveToFile и LoadFromFile - тебе помогут.

С этим уже разобрался. Просто я сначала хотел возиться с ClientDataSet.

> Но ИМХО, ты :
> 1. Выбрал не тот формат данных для обмена. Уж больно он
> нептимальный.

Может и не оптимальный, но моя прога должна уметь передавать данные также и в другую прогу именно через XML.

> Тебе ой как много еще прийдется попотеть, чтобы пользователи
> тебя перестали бить, когда ты затрешь то что они делали
> пару недель...

Не вижу здесь трудностей. Загружаем в DataSet (A) данные из XML. Берем первую запись из A и получаем значение ключевого поля. Удаляем (каскадно) запись с таким же ключевым полем с SQL Server. Вставляем в SQL Server запись из A. Никаких потерь не вижу. Где могут возникнуть проблемы?

← →
sniknik © (2007-04-24 02:07) [15]

> Где могут возникнуть проблемы?
попробуй загрузить в ADODataSet.LoadFromFile сохраненное ClientDataSet-ом (SaveToFile)... и наоборот. попробуй загрузить табличный xml от мелкософта (наверняка есть в твоей, системе/mssql/инсталляционных пакетах, если поискать)
получилось?

xml вовсе не такое универсальное средство обмена как пытается представить мелкософт (больше всего вариантов откроет мелкософтский IDOM документ, но и с ним бывают проблемы.)
+ проблемы бывают на больших файлах (а они неизбежны при обменах между базами (маленькие только у базюлек.. ;о))). попробуй выгрузи/загрузи не игрушечную таблицу на 10 записей, а реальную на 5-10 миллионов, а после тоже самое в dbf(dBase) и смотри разницу. для обьемов поменьше смотри скорость, размер обменного файла (сравнивай с dBase).

> [14] ZevSS © (24.04.07 00:21)
> Удаляем (каскадно) запись с таким же ключевым полем с SQL Server.

А есть гарантия, что под одним кодом лежат одинаковые сущности?

← →
Jan1 (2007-04-24 08:36) [17]

> Может и не оптимальный, но моя прога должна уметь передавать
> данные также и в другую прогу именно через XML.

У того же ADO.SaveToFile есть параметр сохранять в бинарном виде - выигрыш в несколько раз. Но как правильно заметил sniknik © (24.04.07 02:07) [15], если ты будешь выгружать реальные данные, а не тестовые, то выгрузить можно любой обьем, используя серверный курсор, но к сожалению загрузить у тебя не получиться большие выборки через ADO. Я бы рекомендовал выгружать и загружать BULK INSERT или делать какую-то промежуточную базу, хотя бы тем же select * into , бекапить ее, а потом просто поднимать там где нужно загрузить:
1. выиграем в скорости
2. объемы не страшны.

> Не вижу здесь трудностей. Загружаем в DataSet (A) данные
> из XML. Берем первую запись из A и получаем значение ключевого
> поля. Удаляем (каскадно) запись с таким же ключевым полем
> с SQL Server. Вставляем в SQL Server запись из A. Никаких
> потерь не вижу. Где могут возникнуть проблемы?

Опять же что значит с SQL Server? Тебе вообще надо определиться, где идет работа - только на удаленных точках? Или на сервере тоже? Могут ли добавлять, редактировать, удалять на удаленных точках данные, которые видны на других удаленных точках? И еще много вопросов. Вот когда ты ответишь на эти вопросы, ты поймешь, что у тебя будут конфликты, и вот разрешить эти конфликты и есть самая главная задача офф-лайн репликации.

Кстати, ты не сказал как ты будешь логировать.

> попробуй загрузить в ADODataSet.LoadFromFile сохраненное
> ClientDataSet-ом (SaveToFile)... и наоборот. попробуй загрузить
> табличный xml от мелкософта (наверняка есть в твоей, системе/mssql/инсталляционных пакетах, если поискать)
> получилось?

Мне это без надобности. Абсолютно. Главное чтобы между моей прогой, установленной в разных местах была возможность обмениваться данными.
А по поводу размера базы данных... Записей будет в главной таблице около 10 тысяч. Расти будет не сильно.

> А есть гарантия, что под одним кодом лежат одинаковые сущности?

Если верить, что GUID обеспечивает уникальность, то да - под одним кодом гарантированно лежат одинаковые сущности.

> [19] ZevSS © (25.04.07 21:59)
> то да - под одним кодом гарантированно лежат одинаковые сущности.
Остается надеяться, что только под одним.

← →
Jan1 (2007-04-26 12:42) [21]

> Главное чтобы между моей прогой, установленной в разных
> местах была возможность обмениваться данными.

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

Репликация БД и глобальный поиск Найти похожие ветки