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

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

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

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

Спасибо.

Здравствуйте, AndrewK, Вы писали:

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

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

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

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

AK>Спасибо.

О!Это целая корпоративная логика ИТ- структуры, что называется "с нуля".Однозначно, применение субд Oracle, желательно на *nix серверах. Тут требуются советы квал-х администраторов и архитекторов. Вопрос в другом: какой бУджет на это отводится — от этого и отталкиваться. Времени нет на поиски статей, но найтти вполне возможно... Удачи!

Здравствуйте, AndrewK, Вы писали:

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

Т.е. у тебя получается, что сервер среднего звена будет по отношению к одним и тем же данным выступать и как подписчик при общении с вышестоящим сервером и как публикатор при общении с подчиненными серверами? За исключением этого момента все описаное тобой вполне укладывается в стандартные механизмы репликации любой промышленной СУБД...

Здравствуйте, AndrewK, Вы писали:

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

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

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

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

AK>Спасибо.
Делаю аналогичную систему. Для одной из крупнейших компаний России. Тоже всякие правила на тему редактирования справочников — на верхнем сервере можно редактировать одну часть справочников, на серверах 2-го уровня другую часть, на серверах уровнем ниже вообще нельзя редактировать их. Данные должны идти только на нужные серера и т.п.
Использую MS SQL2k как сервер БД, репликацию для переноса данных, MS AS (OLAP) для построения отчетов. Размер данных уже большой, ожидается что дальше будет около 1 Тб. Сложности есть, но все решается. Полезно хорошо изучить репликацию и SQL Server. Почитай книги по этой теме.

Здравствуйте, AndrewK, Вы писали:

Репликаций СУБД не сделаешь. Просто поверь.
Мне тоже такая задача интересна, но я рассматривал еще распределение нагрузки за счет использования служб сообщений. Кроме того средствами СУБД даже не думаю пользоваться.
Попробую вечером сформулировать идеи. Но основа дизайна — Каждая запись должна иметь одного владельца. А как она "гуляет по СУБД" все ровно.
IMHO

Здравствуйте, AndrewK, Вы писали:

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

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

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

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

AK>Спасибо.


Один десятипроцессорный мегасервак + ГигабитЭзернет ко всем клиентам.

Здравствуйте, denger398, Вы писали:

D>О!Это целая корпоративная логика ИТ- структуры, что называется "с нуля".Однозначно, применение субд Oracle, желательно на *nix серверах. Тут

А можно спросить откуда такой "однозначный" вывод? Непременно оракл и непременно на никсах — может стоит привести хоть какое-то обоснование?

Здравствуйте, AndrewK, Вы писали:

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

AK>Есть задача спроектировать систему учета, которая должна работать в нескольких территориально удаленных организациях. Структура системы примерно

Создаю подобное — репликация выборочных данных из таблиц, настраиваемая пользователем + row level security. Делать самому и руками.

Здравствуйте, _d_m_, Вы писали:

___>Здравствуйте, denger398, Вы писали:

D>>О!Это целая корпоративная логика ИТ- структуры, что называется "с нуля".Однозначно, применение субд Oracle, желательно на *nix серверах. Тут

___>А можно спросить откуда такой "однозначный" вывод? Непременно оракл и непременно на никсах — может стоит привести хоть какое-то обоснование?

Я думаю обоснование тут одно — это 'круче' звучит. Другой разумной причины не вижу.

Здравствуйте, andsm, Вы писали:

A>Здравствуйте, _d_m_, Вы писали:

___>>Здравствуйте, denger398, Вы писали:

D>>>О!Это целая корпоративная логика ИТ- структуры, что называется "с нуля".Однозначно, применение субд Oracle, желательно на *nix серверах. Тут

___>>А можно спросить откуда такой "однозначный" вывод? Непременно оракл и непременно на никсах — может стоит привести хоть какое-то обоснование?

A>Я думаю обоснование тут одно — это 'круче' звучит. Другой разумной причины не вижу.

Я почему-то тоже так подумал. Человек может даже и не работал с ораклом — так от знакомых слышал "да... оракл — это круто..." и на любой вопрос на который не может ответить: "ну здесь тебе нужен оракл, и лучше на никсах, да и серверок так процессоров 64 и т.д."

A>Я думаю обоснование тут одно — это 'круче' звучит. Другой разумной причины не вижу.

ну другая например oracle streams replication — техноглогия как раз для решения именно такой задачи.
достаточно круто в сравнении с конкурентами.

Здравствуйте, <Аноним>, Вы писали:

А>ну другая например oracle streams replication — техноглогия как раз для решения именно такой задачи.

А можно в двух словах — что это такое?

L>А можно в двух словах — что это такое?

http://zeus.sai.msu.ru:7000/database/oracle/streams/

Здравствуйте, Аноним, Вы писали:

A>>Я думаю обоснование тут одно — это 'круче' звучит. Другой разумной причины не вижу.

А>ну другая например oracle streams replication — техноглогия как раз для решения именно такой задачи.
А>достаточно круто в сравнении с конкурентами.

Точно такую же задачу по репликации, которая была приведена в начальном сообщении, я решаю стандартными средствами репликации SQL Server. Работает хорошо. Чем oracle streams replication в этом случае будет лучше не вижу.

A>Точно такую же задачу по репликации, которая была приведена в начальном сообщении, я решаю стандартными средствами репликации SQL Server. Работает хорошо. Чем oracle streams replication в этом случае будет лучше не вижу.

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

ЗЫ. SQL Server по http и ftp не умеет

Здравствуйте, Аноним, Вы писали:

A>>Точно такую же задачу по репликации, которая была приведена в начальном сообщении, я решаю стандартными средствами репликации SQL Server. Работает хорошо. Чем oracle streams replication в этом случае будет лучше не вижу.

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

А>ЗЫ. SQL Server по http и ftp не умеет
По ftp умеет.

А>>а разве в стандартной репликации можно писать правила, трансформировать в пути данные или использовать узел просто для передачи транзакций на след. узел ?
A>Можно

а можно урл где об этом почитать ? на msdn неисчется.

Здравствуйте, Аноним, Вы писали:


А>>>а разве в стандартной репликации можно писать правила, трансформировать в пути данные или использовать узел просто для передачи транзакций на след. узел ?
A>>Можно

А>а можно урл где об этом почитать ? на msdn неисчется.

Искать по DTS Transformation, replication filters

Здравствуйте, AndrewK, Вы писали:

Это сугубо моё личное мнение основанное на личном опыте
перелаживать такие задачи на плечи СУБД не логично т.к.
обьяснить серверу какие справочники обновлять какие не
обновлять и какие конкретно записи и почему по моему
слишком.
Я делаю всегда мастер(а) импорта-экспорта данных и уже
основываясь на конкретных условиях формирую SQL скрипт
обновления на головном сервере и исполняю его на
подчиненном сервере. Получаем гибкую систему для
перестройки которой под новые бизнес условия
нужно подправить(переписать )тока мастера который живет
сам по себе.
Если чё не так я не виноват