Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2004.08.15;
Скачать: [xml.tar.bz2];

Вниз

Построение системы с распределенной базой данных.   Найти похожие ветки 

 
AndrewK   (2004-07-21 10:44) [0]

Доброго времени суток всем!

Есть задача спроектировать систему учета, которая должна работать в нескольких территориально удаленных организациях. Структура системы примерно такова: Есть несколько организаций, которые содержат, например, по одному серверу с установленной базой данных. Дальше буду оперировать серверами. Серверы логически организуются в виде иерархической структуры. Головной сервер имеет привилегию модерировать справочники, которые должны передаваться на подчиненные по структуре сервера. Есть часть справочников, которые могут правиться на нижних уровнях, например местные контрагенты, местные товары и т.д. Эти данные должны реплицироваться н вышестояшие сервера. Для простоты и масштабируемости принимаем, что сервер общается только с одним вышестоящим сервером и с первым рядом подчиненных серверов (получается маленький сетевой маркетинг :) ). По определенному регламенту или по требованию данные реплицируются между серверами.

Теперь сам вопрос:  Какими способами можно реализовать подобную схему работы? Какие инструменты лучше использовать? Посоветуйте какие-нибудь книги, лучше электронные, статьи, ссылки по данной теме. Если не трудно, то подкиньте несколько идей.

P.S. Сейчас использую MS SQL Server 2000.

Спасибо.


 
Fiend ©   (2004-07-21 10:53) [1]

Способ - репликация. У сервера есть все механизмы для этого.
В качестве инструмента наверное голова. А книг по СКЛ серверу валом, надо только про репликацию почитать и разобраться


 
AndrewK   (2004-07-21 12:50) [2]

Валом - это точно. Только практически все что встречается - мусор или водичка. Интернет пока тоже сопротивляется.
Например, не могу найти нормального хелпа о том, как настроить репликацию через Интернет. Есть какая-нибудь информация по этому поводу?


 
Reindeer Moss Eater ©   (2004-07-21 12:59) [3]

Репликация через инет для MSSQL делается средстсвами FTP.
В любой книге по администированию написано.


 
Курдль ©   (2004-07-21 13:22) [4]


> AndrewK   (21.07.04 10:44)  

Я думаю, что с такой архитектурой Вы задибидохаетесь с мягким знаком. Если иметь централизованный сервер и локальные, реплицируемые с ним - это еще можно понять (хотя идеал - это один сервер и удаленные клиенты). Но иметь целую многоуровневую структуру - это уже слишком! Зачем? Вы готовы расписать строгие бизнес-правила для такой репликации с условием целостности данных?


 
AndrewK   (2004-07-21 17:32) [5]

Вся проблема в организации бизнеса. Есть центральный офис, есть региональные представительства, есть отделения региональных представительств. Каждый узел работает со своим набором данных. На вышестоящих уровнях нужна консолидированная отчетность по контролируемому бизнесу. Узлы могут быть не равноправны, например один занимается торговлей и у него есть склад и управление заказами, а второй занимается производством и у него есть склад и производство. Плюс одно из требований в любой момент любую ветку можно отделить, верхнему узлу дать привелегии управления общими справочниками и отправить в самостоятельное плавание.

Задачка не кислая - понимаю. Поэтому и пытаюсь прежде чем бросаться делать порассуждать. Проводил эксперименты с репликацией - получается не совсем то, что надо. Хотя может что-то не так делаю. Думаю сперва надо сесть и действительно продумать бизнес процессы репликации. Возможно здесь подойдет только самодельная разработка.


 
Курдль ©   (2004-07-21 17:39) [6]

Может тогда следует продумать механизм электронной отчетности, а не репликации? Ведь механизм репликации предусматривает синхронизацию данных с наименьшим трафиком. Нужно ли иметь "во всем мире" БД с идентичными данными?


 
Sergey13 ©   (2004-07-21 17:46) [7]

2AndrewK   (21.07.04 17:32) [5]
А вся эта система (системища я бы сказал) будет делаться тобой одним или у тебя за плечами некислая контора? Если первое - то или сбежать или застрелиться, ИМХО. 8-(


 
AndrewK   (2004-07-22 09:09) [8]

>> Sergey13
Как говорил один умный человек: "Не бывает нереальных целей - бывают нереальные сроки".
Всю систему сразу делать никто и не собирается. Сначала что-нибудь маленькое, потом побольше ну и т.д.
А сбежать всегда успеется...  :)


 
Sergey13 ©   (2004-07-22 09:40) [9]

2AndrewK   (22.07.04 09:09) [8]
Тогда и писать надо "Сначала что-нибудь маленькое". А мысли о "мировом масштабе" оставить на потом. Все равно любой модуль системы должен работать прежде всего автономно. А когда ты все напишешь (через реальные сроки 8-) каналы связи будут широкие и скоростные, как хайвеи в Америке.


 
Draught ©   (2004-07-22 10:21) [10]

Есть очень хорошая книжка, брал в Мск, в прошлом году летом за 500 рэ... Справочник администратора Microsoft SQL Server 2000 | М.Ф. Гарсиа, Дж. Рединг, Э. Уолен, С.А.ДеЛюк. Издательство ЭКОМ Москва, 2002... Собственно там очень много всего есть по поводу репликации БД... ))))))


 
AndrewK   (2004-07-22 10:38) [11]

>> Sergey13

Маленькое уже написано. Есть локальное решение, в котором работает порядка 100 чел (ну реально около 50 в среднем). Делает кучу всякой работы, но это в принципе не важно...  Не сочтите за хвастовство - просто описал ситуацию.  Вопрос о распределенке возник так. Один менеджер отправился работать в филиал и был очень удивлен, когда у него в другом городе не запустилось это приложение. Отсюда все и закрутилось.
А насчет мыслей о "глобальном масштабе" - думаю сто мыслить как раз и надо в глобальных масштабах, а потом спускаться пониже и мыслеть уже более детально. Так получается большая направленость на цель. Да и котролировать развитие системы тоже так легче. Конечно ИМХО.

>> Draught
Спасибо. Поищу.


 
AndrewK   (2004-07-22 10:46) [12]

Что-то я нагородил ошибок...  :(

Исправляюсь:

А насчет мыслей о "глобальном масштабе" - думаю что мыслить как раз и надо в глобальных масштабах, а потом спускаться пониже и мыслить уже более детально. Так получается большая направленность на цель. Да и контролировать развитие системы тоже так легче. Конечно ИМХО.


 
Курдль ©   (2004-07-22 10:51) [13]

Вы только не ошибитесь с выбором СУБД для глобальных целей и не напишите под MS SQL.


 
AndrewK   (2004-07-22 10:57) [14]

А чем так плох MS SQL? Кроме платформозависимости?


 
Sergey13 ©   (2004-07-22 11:14) [15]

2AndrewK   (22.07.04 10:38) [11]
По такой схеме, решив слабать свой калькулятор, надо задуматься над созданием сервера калькуляции в инете, и что бы каждая локальная копия проги решала в рантайме - самой вычислять или отослать это серверу (с выбором зеркал ессно 8-). А у того менеджера может какой нить БДЕ был не настроен. 8-)


 
AndrewK   (2004-07-22 11:42) [16]

>> Sergey13
От BDE давно отказался.  :)

По такой схеме, решив слабать свой калькулятор, надо задуматься над созданием сервера калькуляции в инете...
Задуматься все же стоит, хотя бы для того, чтобы отмести эту возможность. В моем конкретном случае я же не калькулятор проектирую.

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


 
Sergey13 ©   (2004-07-22 12:11) [17]

2AndrewK   (22.07.04 11:42) [16]
>В общем, я уже понял, здесь скорее вопрос регламента и бизнес-процессов, чем репликации.
А по моему наоборот. 8-)
Основное непонимание (у меня по крайней мере) вызвала твоя фраза в вопросе
>Дальше буду оперировать серверами. Серверы логически организуются в виде иерархической структуры.

Причем тут сервера? Какие сервера? БД? Приложений? Почтовые? На уровне организации данных - твоя задача достаточно стандартна (хоть и сложна на больших объемах). Репликация может быть как стандартными средствами так и самописной.
Все ИМХО, т.к. репликацией я вплотную не занимался, только читал.


 
AndrewK   (2004-07-22 13:17) [18]

>> Sergey13
>Основное непонимание (у меня по крайней мере) вызвала твоя фраза в вопросе
>>Дальше буду оперировать серверами. Серверы логически организуются в виде иерархической структуры.


Здесь речь идет о логической организации. Под сервером я понимал сервер БД на котором крутится информационная система. Каждый сервер равноправен друг с другом. Разница только в логике соединения. Например этот будет главным, а этот подчиненным. И задача их в общем случае будет такая:

Задача подчиненного - забрать у главного справочники.
Задача главного     - забрать у подчиненного первичные документы.

Работа самой системы на местах ничем не отличается от работы в центре. Разница только в наличии разного объема данных.

Репликация здесь выступает только как инструмент. Сама по себе она решает только техническую задачу переноса данных между серверами. Задачу информационной системы она не решает.


 
Sergey13 ©   (2004-07-22 14:59) [19]

2AndrewK   (22.07.04 13:17) [18]
>Разница только в наличии разного объема данных.

>Сама по себе она (репликация) решает только техническую задачу переноса данных между серверами.

ИМХО, ты сам себе противоречишь. Не находишь? Сколько закачал данных - столько и имеешь. Т.е. какую репликацию сделаешь, такие данные и будешь иметь в каждом конкретном месте.

>Задачу информационной системы она не решает.
А какова задача то? Что бы не было войны? Репликация вообще ничего не решает, кроме задачи репликации данных между центрами информации (сори за тавтологию 8-). Для того и придумана.



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2004.08.15;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.51 MB
Время: 0.03 c
14-1091033833
Art_Z
2004-07-28 20:57
2004.08.15
Хочу книгу по железу!


14-1091174607
Kreogen
2004-07-30 12:03
2004.08.15
BOX или не BOX


1-1091364760
oleg_SYS
2004-08-01 16:52
2004.08.15
Создание файла компонентом в Design-тайме


8-1085741333
Musiy
2004-05-28 14:48
2004.08.15
Полупрзрачность


14-1090898346
Hooch
2004-07-27 07:19
2004.08.15
delphiplus.org





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский