Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Переход от обычного приложения к распределенному  [new]
Shev
Member

Откуда: с холодного севера
Сообщений: 93
Добрый день.

Есть программа на Делфи + MSSQL, доменная модель, рассчитанная на мелкий и средний бизнес. Программа из области электроэнергетики.

На днях объявился очень крупный заказчик, желающий ее приобрести, если она сможет решить его проблемы.

У заказчика имеется: Головная контора -> Филиалы -> Отделения -> Участки. Фактически наша программа автоматизирует работу участка. Необходимо, чтобы консолидированные (т.е. только итоговые) данные из множества баз данных участков попадали базу данных отделения, к которому они относятся, из нескольких отделений в одну базу по филиалу и из всех филиалов в единственную базу головной конторы.
Имеются удаленные участки в плохой связью (возможно даже модемной).

На участках пользователи рассчитывают потребления по физикам и юрикам и составляют итоговые балансы по ТП (трансформаторным пунктам) первого уровня. В отделениях не интересны ни физики ни юрики, они должны получать данные от участков по ТП первого уровня, составлять схемы и получать итоговые балансы по ТП второго уровня. В филиалах, получив балансы по ТП второго уровня, считают баланс уже на уровне подстанций. А голова составляет балансы по всем подстанциям области.

Проблемы:
1. В таблице везде Identity(1,1). Перечитал форумы и статьи: по любому придется перейти на GUID. С этим объемом работ уже вроде смирился. Проблема в том, чтобы не испортить удобную работу для мелких клиентов, которым очень удобен короткий числовой код. Две версии базы (GUID для крупных и Identity для мелких) поддерживать не реально.
Выход: перевод primary key на GUID и создание еще одного поля для таблиц «контрагенты», «договора», «объекты», «счетчики», в котором будет генерироваться удобный для пользователя код с неким префиксом, а для мелких и вообще без префикса. Но тогда поле получается текстовым и для правильной сортировки выглядеть в стиле 1С: A0000123, A0000124, A0000125, вместо просто 123, 124, 125, и т.д. Возможно, удобнее будет сделать из двух полей «участок» и «числовой код» и накатить индекс из двух полей.
Вопрос: кто как выкручивался с ключевым полем для пользователей?

2. Как наверх передавать только часть данных. Типа у итоговых объектов должна иметься некая галочка и информация по ним передается наверх, а остальные объекты не реплицируются. Возможно ли настроить репликацию части данных или реплицируются тупо все транзакции выполненные в базе данных?

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

Т.е. грубо говоря, в идеале надо чтобы нужные данные летали вверх и вниз и у отделения из деревни Васьково не появлялись объекты из поселка Петрово.

Интересна также любая информация о дополнительных проблемах, с которыми мы можем встретиться.

Заранее спасибо за любую информацию
9 ноя 09, 12:26    [7900811]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5111
ну дак чем репликация не устраивает?
зачем вам гуиды везде понадобились, если вам нужно перегонять только некие "итоги"?
по части "Возможно ли настроить репликацию части данных...?" - да возможно.
т.к перегонять будете только "итоги" транзакционная реплика совсем не нужна.
--------------------------------------------------------------
Дьявол кроется в деталях.
9 ноя 09, 12:48    [7901040]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Shev
Member

Откуда: с холодного севера
Сообщений: 93
На самом деле пока не ясно, что вообще конкретно и как передавать придется. Пока был только один звонок и заданы вопросы, на которые мы не смогли ответить. Поэтому я сейчас прорабатываю разные сценарии, чтобы в следующий раз что-то конкретное можно было им предложить.

Возможно им потребуется гонять всю базу по всей пирамиде, хотя сильно в этом сомневаюсь.
9 ноя 09, 13:04    [7901192]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Shev
Member

Откуда: с холодного севера
Сообщений: 93
Дедушка
ну дак чем репликация не устраивает?
зачем вам гуиды везде понадобились, если вам нужно перегонять только некие "итоги"?
по части "Возможно ли настроить репликацию части данных...?" - да возможно.
т.к перегонять будете только "итоги" транзакционная реплика совсем не нужна.


Под итогами я имел в виду начисления по ТП первого уровня (для участков). Т.е. это всего лишь выборочные записи из одной большой таблицы. Т.е. скажем так: передача не итогов, а выборочных объектов энергосистемы.

Получается по всей пирамиде реплицируется таблица, но чем ниже, тем больше записей в ней содержится и меньших по значимости.
9 ноя 09, 13:10    [7901241]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Esu
Member

Откуда: Киев
Сообщений: 154
можно задавать специальные фильтры на таблицу в настройках репликации
9 ноя 09, 15:04    [7902349]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
tusha
Member

Откуда:
Сообщений: 122
работал 3 года в области учета газа - Главное управление->филиалы
за это время понял следующее по этим вопросам:
1) разработать систему кодификации, identity - простые цыфры не несущие никакой информации
в коде заложить признаки филиалов, отделений и проч.
2,3) передавать только отчеты итоговые (сколько чего по району, учатску ...) т.к. в главном управлении нет смысла знать сколько потребил ИвановИванИванович в этом квартале)
все имхо


они станут толще, мы станем смелей
9 ноя 09, 15:12    [7902443]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Shev
Member

Откуда: с холодного севера
Сообщений: 93
Изучаю репликацию и появились еще вопрос:

Везде описаны случае где один Publisher и несколько подписчиков. У меня же получается, что филиал относительно головной конторы является подписчиком, а для отделений он уже публишер. И соответственно отдел является подписчиком относительно филиала и публишером для участка.

Может по такой схеме работать MSSQL?
9 ноя 09, 15:16    [7902482]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Denis__Ka
Member

Откуда: Москва
Сообщений: 121
Shev,
а можно привести пример, когда потребуется "репликация" сверху вниз?
имхо, это не совсем отвечает принципу надежности и адекватности данных -
первоисточник данных всегда один. Все остальное от лукавого.
Т.е. снизу вверх - понятно, обратно быть не должно.
9 ноя 09, 15:25    [7902576]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
ura
Member [заблокирован]

Откуда: Киев
Сообщений: 932
2 Shev
автор

1. В таблице везде Identity(1,1). Перечитал форумы и статьи: по любому придется перейти на GUID. С этим объемом работ уже вроде смирился. Проблема в том, чтобы не испортить удобную работу для мелких клиентов, которым очень удобен короткий числовой код. Две версии базы (GUID для крупных и Identity для мелких) поддерживать не реально.

Есть еще вариант перехода на bigint, по объему работ будет существенно менее затратным, чем переход на guid.

По поводу п.п. 2,3 - читайте про merge-репликацию.
9 ноя 09, 15:45    [7902788]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Glory
Member

Откуда:
Сообщений: 104760
Shev

Проблемы:
1. В таблице везде Identity(1,1). Перечитал форумы и статьи: по любому придется перейти на GUID. С этим объемом работ уже вроде смирился. Проблема в том, чтобы не испортить удобную работу для мелких клиентов, которым очень удобен короткий числовой код.

У вас пользователи настолько суровы, что запоминают и оперируют ПервичнымиКлючами записей ?
Мне казалось, что суррогатные ПК служат для других целей.
9 ноя 09, 15:48    [7902814]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Shev
Member

Откуда: с холодного севера
Сообщений: 93
Denis__Ka
Shev,
а можно привести пример, когда потребуется "репликация" сверху вниз?
имхо, это не совсем отвечает принципу надежности и адекватности данных -
первоисточник данных всегда один. Все остальное от лукавого.
Т.е. снизу вверх - понятно, обратно быть не должно.


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

Вообще получается что реплицировать нужно данные объектов расположенных на границах ответственности между уровнями. Т.е. Отдел снимает показания по ТП, рассчитывает переданную электроэнергию и спускает эту инфу Участку. Участок получив эти данные и зная как у него распределяется электроэнергия, т.е. сколько из полученной он продал и сколько составили потери подытожил (составил баланс по этой ТП) и передал информацию обратно в Отдел.

Когда у Отдела появится информация о балансе от всех Участков по их ТП, он уже может составлять свой баланс по более крупным ТП, для которых переданный объем электроэнергии он получил от вышестоящего филиала.
И так между каждым слоем.

Так вот: где здесь подписчики и где публишеры?
9 ноя 09, 15:56    [7902902]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Glory
Member

Откуда:
Сообщений: 104760
Shev
Denis__Ka
Shev,
а можно привести пример, когда потребуется "репликация" сверху вниз?
имхо, это не совсем отвечает принципу надежности и адекватности данных -
первоисточник данных всегда один. Все остальное от лукавого.
Т.е. снизу вверх - понятно, обратно быть не должно.


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

"Схема подключения" - это справочники что ли ?
9 ноя 09, 15:59    [7902929]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Shev
Member

Откуда: с холодного севера
Сообщений: 93
Glory

У вас пользователи настолько суровы, что запоминают и оперируют ПервичнымиКлючами записей ?
Мне казалось, что суррогатные ПК служат для других целей.


При общении с клиентами и сотрудниками других организаций естественно общение идет по имени+адресу+контрагенту.

Но между собой очень часто слышны высказывания в стиле:
"У меня по 682 объекту вылезли большие потери"; "Глянь 705, здесь явно что-то не то" и т.п.
В записках друг другу указывают просто код для быстрого поиска.
И это у всех клиентов.
9 ноя 09, 16:03    [7902969]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Glory
Member

Откуда:
Сообщений: 104760
Shev
Glory

У вас пользователи настолько суровы, что запоминают и оперируют ПервичнымиКлючами записей ?
Мне казалось, что суррогатные ПК служат для других целей.


При общении с клиентами и сотрудниками других организаций естественно общение идет по имени+адресу+контрагенту.

Но между собой очень часто слышны высказывания в стиле:
"У меня по 682 объекту вылезли большие потери"; "Глянь 705, здесь явно что-то не то" и т.п.
В записках друг другу указывают просто код для быстрого поиска.
И это у всех клиентов.

И какое отношение этот "код объекта" имеет к ПК ? Почему пользователь его вообще видит ?
9 ноя 09, 16:04    [7902985]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
iljy
Member

Откуда:
Сообщений: 8711
Shev
Glory

У вас пользователи настолько суровы, что запоминают и оперируют ПервичнымиКлючами записей ?
Мне казалось, что суррогатные ПК служат для других целей.


При общении с клиентами и сотрудниками других организаций естественно общение идет по имени+адресу+контрагенту.

Но между собой очень часто слышны высказывания в стиле:
"У меня по 682 объекту вылезли большие потери"; "Глянь 705, здесь явно что-то не то" и т.п.
В записках друг другу указывают просто код для быстрого поиска.
И это у всех клиентов.

ну так оставьте identity как ключ внутри базы, а дополнительно заведите uniqueidentifier и используйте его при реплике.
9 ноя 09, 16:06    [7902995]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Shev
Member

Откуда: с холодного севера
Сообщений: 93
Glory

"Схема подключения" - это справочники что ли ?


Спровочник - это "Объекты". А схема подключения это уже журнал присоединений, а также информация о включениях и отключениях (дата, примечание и др. информация)
9 ноя 09, 16:06    [7902996]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Glory
Member

Откуда:
Сообщений: 104760
Shev
Glory

"Схема подключения" - это справочники что ли ?


Спровочник - это "Объекты". А схема подключения это уже журнал присоединений, а также информация о включениях и отключениях (дата, примечание и др. информация)

Имхо. Вы путаете хранение и визуализацию данных
В центральном хранилище должны быть все данные от первоисточников.
А для их отображения должны использоваться нереплицируемые объекты, которые будут подсчитывать итоги с их отображением нужного "масштаба"
9 ноя 09, 16:10    [7903028]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Shev
Member

Откуда: с холодного севера
Сообщений: 93
Glory

И какое отношение этот "код объекта" имеет к ПК ? Почему пользователь его вообще видит ?


А почему бы и нет? Мне нужен был ПК. Вполне естественно было использовать identity. А пользователям назначаемый автоматически номер тоже удобен. Зачем здесь что-то новое выдумывать? Пока нет репликации, все прекрасно!

Честно говоря, это немного в сторону от основной проблемы с репликацией.
9 ноя 09, 16:12    [7903050]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Shev
Member

Откуда: с холодного севера
Сообщений: 93
Glory

Имхо. Вы путаете хранение и визуализацию данных
В центральном хранилище должны быть все данные от первоисточников.
А для их отображения должны использоваться нереплицируемые объекты, которые будут подсчитывать итоги с их отображением нужного "масштаба"


А отсюда хотелось бы поподробней. Получается, что в головной компании будут храниться абсолютно все данные вплоть до участка (т.е. гаражи и ларьки). Но это не их уровень. Головная управляет несколькими республиками и областями нашей страны. И в ее базе хранить миллионы не нужной ей информации абсолютно не интересно.

И все же еще раз задам вопрос: как с репликацией через несколько уровней?
9 ноя 09, 16:18    [7903104]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Glory
Member

Откуда:
Сообщений: 104760
Shev
Glory

Имхо. Вы путаете хранение и визуализацию данных
В центральном хранилище должны быть все данные от первоисточников.
А для их отображения должны использоваться нереплицируемые объекты, которые будут подсчитывать итоги с их отображением нужного "масштаба"


А отсюда хотелось бы поподробней. Получается, что в головной компании будут храниться абсолютно все данные вплоть до участка (т.е. гаражи и ларьки). Но это не их уровень. Головная управляет несколькими республиками и областями нашей страны. И в ее базе хранить миллионы не нужной ей информации абсолютно не интересно.

И все же еще раз задам вопрос: как с репликацией через несколько уровней?

Почему не нужной то ? Это информация для получения итогов.
9 ноя 09, 16:20    [7903123]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Shev
Member

Откуда: с холодного севера
Сообщений: 93
iljy

ну так оставьте identity как ключ внутри базы, а дополнительно заведите uniqueidentifier и используйте его при реплике.


А как быть с пересечением identity?

Отмечу, что наше приложение коммерческое тиражируемое ПО. И у других схема репликации может быть другой. Поэтому переделав на GUID, мы с новыми клиентами, которым нужна репликация будем общаться гораздо смелее.
9 ноя 09, 16:23    [7903159]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5111
Glory
Почему не нужной то ? Это информация для получения итогов.

на сколько я понял автора, речь не о создании центрального хранилища, а о "распределённом" без дрилдауна. т.е. центр получает: "Регион1=10, Регион2=20" и далее чтото с этим делает без вникания откуда взялись эти числа.
9 ноя 09, 16:24    [7903166]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Glory
Member

Откуда:
Сообщений: 104760
Дедушка
Glory
Почему не нужной то ? Это информация для получения итогов.

на сколько я понял автора, речь не о создании центрального хранилища, а о "распределённом" без дрилдауна. т.е. центр получает: "Регион1=10, Регион2=20" и далее чтото с этим делает без вникания откуда взялись эти числа.

Ну тогда это не репликация в ее классическом понимании
А передача итоговых данных.
9 ноя 09, 16:25    [7903181]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Shev
Member

Откуда: с холодного севера
Сообщений: 93
Glory
Shev
Glory

Имхо. Вы путаете хранение и визуализацию данных
В центральном хранилище должны быть все данные от первоисточников.
А для их отображения должны использоваться нереплицируемые объекты, которые будут подсчитывать итоги с их отображением нужного "масштаба"


А отсюда хотелось бы поподробней. Получается, что в головной компании будут храниться абсолютно все данные вплоть до участка (т.е. гаражи и ларьки). Но это не их уровень. Головная управляет несколькими республиками и областями нашей страны. И в ее базе хранить миллионы не нужной ей информации абсолютно не интересно.

И все же еще раз задам вопрос: как с репликацией через несколько уровней?

Почему не нужной то ? Это информация для получения итогов.


Не нужно головной конторе, чтобы получить баланс электроэнергии по крупным подстанциям и фидерам, знать потребление по ларькам в деревне Гадюкино. Деревня Гадюкино учлась в ниже лежащем балансе, который свел Участок №3 и вернул в виде потребления по их мелкой ТП-шке.

Каждая база последующего уровня - это абстрагирование от мелочей и работа на более крупном уровне.

Я даже не представляю, сколько будет времени считаться баланс на уровне нескольких областей если его считать начиная от ларьков и сколько будет гоняться никому не нужных данных.
9 ноя 09, 16:30    [7903230]     Ответить | Цитировать Сообщить модератору
 Re: Переход от обычного приложения к распределенному  [new]
Glory
Member

Откуда:
Сообщений: 104760
Shev


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

Еще раз - вы путаете понятия "хранить" и "отображать"
9 ноя 09, 16:33    [7903252]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить