RUS  ENG 

Журнал потребителей

Страницы: 1
RSS
Журнал потребителей
 
Добрый день. Имеется слой инженерной сети, потребители в котором представляют из себя отдельных абонентов, а не тепловые вводы в здание. Т.е визуально это выглядит как "куст потребителей".

https://imgur.com/tcMRitd

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


В данный момент у нас имеется 2 решения:
1) Просто отделить абонентов от сети, чтобы они не участвовали в расчете и "висели в воздухе" рядом со вводом.
2) Настроить базу данных потребителей следующим образом:
1. Создать дополнительную таблицу, SQLserver которая будет помимо sys иметь ID - счетчик (идентификатор), в этой таблице будет храниться информация об абонентах;
https://imgur.com/eos4A0G , https://imgur.com/AzScO0b
2. В запросе связываем таблицы sys -> sys связь много к одному. Поле связи с картой - sys основной таблицы.
https://imgur.com/feSxz6X
3. В последствии при просмотре информации потребителя появится некий журнал, в который можно будет занести всех абонентов. Т.е ставим 1 потребитель, который символизирует тепловой ввод в здание, в нем есть строки из второй таблицы (журнала), листая которые мы переключаемся между абонентами.

Нам предпочтителен второй вариант.
Вопросы:
1) Можно ли использовать второй вариант? Не возникнут ли в последствии конфликты?
2) Если второй вариант можно использовать - каким образом можно автоматически или полуавтоматически (с помощью запросов, либо макросов) просуммировать нагрузку всех абонентов теплового ввода и добавить ее в соответствующее расчетное поле?
 
Цитата
написал:
Добрый день. Имеется слой инженерной сети, потребители в котором представляют из себя отдельных абонентов, а не тепловые вводы в здание. Т.е визуально это выглядит как "куст потребителей".

https://imgur.com/tcMRitd

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


В данный момент у нас имеется 2 решения:
1) Просто отделить абонентов от сети, чтобы они не участвовали в расчете и "висели в воздухе" рядом со вводом.
2) Настроить базу данных потребителей следующим образом:
1. Создать дополнительную таблицу, SQLserver которая будет помимо sys иметь ID - счетчик (идентификатор), в этой таблице будет храниться информация об абонентах;
https://imgur.com/eos4A0G , https://imgur.com/AzScO0b
2. В запросе связываем таблицы sys -> sys связь много к одному. Поле связи с картой - sys основной таблицы.
https://imgur.com/feSxz6X
3. В последствии при просмотре информации потребителя появится некий журнал, в который можно будет занести всех абонентов. Т.е ставим 1 потребитель, который символизирует тепловой ввод в здание, в нем есть строки из второй таблицы (журнала), листая которые мы переключаемся между абонентами.

Нам предпочтителен второй вариант.
Вопросы:
1) Можно ли использовать второй вариант? Не возникнут ли в последствии конфликты?
2) Если второй вариант можно использовать - каким образом можно автоматически или полуавтоматически (с помощью запросов, либо макросов) просуммировать нагрузку всех абонентов теплового ввода и добавить ее в соответствующее расчетное поле?
Добрый день. В версии 2021 в расчеты добавлена возможность выполнять автоматичесмки SQL запросы до и после выполнения расчета.
Например, можно перед просуммировать нагрузку по субабонентам и записать сумму в поле расчетной нагрузки
https://www.politerm.com/zuluthermo/webhelp/index.html#data_processing.html
 

В дополнении к вопросу:

1. Так вариант №2 со связкой таблиц является допустимым и не приведет к каким-либо конфликтам на уровне БД? Не заявлялись или реализовывались еще какие-либо варианты решения вопроса учета нагрузок различных потребителей от одного смесительного узла МКД?

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

 
Цитата
написал:
В дополнении к вопросу: 1. Так вариант №2 со связкой таблиц является допустимым и не приведет к каким-либо конфликтам на уровне БД? Не заявлялись или реализовывались еще какие-либо варианты решения вопроса учета нагрузок различных потребителей от одного смесительного узла МКД? 2. При необходимости отключения нагрузок одного из встроенных потребителей, например, при расчете режима летнего ГВС (ГВС не использует, опломбирован), будет необходимо исключать эти нагрузки вручную или вводить в связанную таблицу параметр использования нагрузки?
1. По словесному описанию варианта организации данных трудно сказать определенно, заработает он или нет. Нужно конкретную структуру проверять. Проверьте
2. Для автоматического выполнения запроса по пред подготовке исходных данных признаков должно быть достаточно. Если какая-то нагрузка в данный момент не работает, должен быть признак, что не работает. Другое дело, что у нас в опциях для выполнения запроса сейчас указывается только тип расчета (наладка, поверка и т.д.) А летний не летний не указывается. Можем дополнить. Что такой-то расчет выполняется для поверки и только для летнего режима.
Страницы: 1