|
|
|
Проектирование БД для хранение электричских сетей
|
|||
|---|---|---|---|
|
#18+
НУжно спроектировать бд для хранения электрических сетей. Сеть довольно разветвленная эл сеть. Если абстрагироваться, то щас храню сеть в виде графа. 1. Есть таблица объектов (узлы графа) tObj (id int, name varchar, typeObj int) 2. Есть таблица связей (связи графа) tRelation (id int, destpoint int, sourcepoint int, edge int) - edge - линия целиком - собираеться из relation Все как бы хранится, и грузиться, новот всякие рачсеты со схемой производятся довольно долго Например рачет Элемента питания (узла питания) - нужно от объекта бежать по всем его relation дальше от каждого relation к другому и так далее... Вот здесь возникает вопрос, есть ли какой нибудь более оптимальный способ хранения и "расчета" схемы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2011, 09:11 |
|
||
|
Проектирование БД для хранение электричских сетей
|
|||
|---|---|---|---|
|
#18+
Раздели задачи хранения и обработки данных. Хранить нужно в таком виде, как удобно для СУБД. Для обработки данные загружаем из БД в оперативную память и переформатируем так, как удобно для расчётов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2011, 09:34 |
|
||
|
Проектирование БД для хранение электричских сетей
|
|||
|---|---|---|---|
|
#18+
mcureenabРаздели задачи хранения и обработки данных. Хранить нужно в таком виде, как удобно для СУБД. Для обработки данные загружаем из БД в оперативную память и переформатируем так, как удобно для расчётов. вот в этом возникает проблемка... в некторых задачках данная схема вся не нужна, и не надо ее грузить полностью в память (тоже довольно не быстрый процесс). А просчитать часть схемки нужно, вот поэтому я и задал жанный вопрос. а то что вы предложили, по сути щас у меня это и есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2011, 10:53 |
|
||
|
Проектирование БД для хранение электричских сетей
|
|||
|---|---|---|---|
|
#18+
virus_system, т.е. проблема в длительной загрузке данных в процесс программы расчёта? возможно требуется оптимизировать запросы к БД. наверное объекты можно постоянно держать в оперативной памяти. т.е. сделать некую специализированную объектную in memory database. или как то кластеризовать данные, чтобы загружать для расчёта не сеть объектов (только нужных для расчёта, но долго), а некий кластер (в котором есть все нужные и некоторые ненужные объекты, но зато быстро). не знаю, как там у тебя устроено и какого масштаба сеть, могу предположить, что в кластер можно собрать все объекты района, здания, этажа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2011, 11:17 |
|
||
|
Проектирование БД для хранение электричских сетей
|
|||
|---|---|---|---|
|
#18+
virus_systemно вот всякие расчеты со схемой производятся довольно долго. Например рачет Элемента питания (узла питания) - нужно от объекта бежать по всем его relation дальше от каждого relation к другому и так далее... Вот здесь возникает вопрос, есть ли какой нибудь более оптимальный способ хранения и "расчета" схемы? Есть. 1. Неплохо было бы узнать, в какой СУБД хранишь данные 2. Как реализуешь алгоритм "от объекта бежать по всем его relation дальше от каждого relation к другому и так далее". Поскольку схема меняется нечасто, есть вариант готовить и хранить промежуточные данные - в виде, более эффективном для дальнейшей обработки. Например, если твоя таблица связей графа содержит только связи между ближайшими точками, то хранить ещё и расчёты, связанные не только с непосрдественно соединёнными узлами. Способов много, но чтобы понять, какой подходит тебе, нужно блоьше понимать алгоритмы расчётов, которые ты реализовал и как ты их уже реализовал... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2011, 11:37 |
|
||
|
Проектирование БД для хранение электричских сетей
|
|||
|---|---|---|---|
|
#18+
АнатоЛойЕсть. 1. Неплохо было бы узнать, в какой СУБД хранишь данные 2. Как реализуешь алгоритм "от объекта бежать по всем его relation дальше от каждого relation к другому и так далее". 1. СУБД - SQL Server 2005 2. есть алгоритм на клиенте (но эдля этого нужна полная загрузка схемы), и есть алгоитрм на самой субд - реализовано с помощью рекурсивног запроса ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2011, 11:43 |
|
||
|
Проектирование БД для хранение электричских сетей
|
|||
|---|---|---|---|
|
#18+
АнатоЛойПоскольку схема меняется нечасто, есть вариант готовить и хранить промежуточные данные - в виде, более эффективном для дальнейшей обработки. Например, если твоя таблица связей графа содержит только связи между ближайшими точками, то хранить ещё и расчёты, связанные не только с непосрдественно соединёнными узлами. Способов много, но чтобы понять, какой подходит тебе, нужно блоьше понимать алгоритмы расчётов, которые ты реализовал и как ты их уже реализовал... Ну я бы не сказал что схема довольно редко меняется. Например на связях есть коммутационные аппараты, которые отвечают (грубо говоря) за то что включена связь или нет. Так вот при отключении/включении некоторых коммутационных аппаратов может довольно много поменяться в схеме, вплоть до направления электричества ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2011, 11:46 |
|
||
|
Проектирование БД для хранение электричских сетей
|
|||
|---|---|---|---|
|
#18+
virus_system Вот здесь возникает вопрос, есть ли какой нибудь более оптимальный способ хранения и "расчета" схемы? http://www.osp.ru/pcworld/2007/03/4199032/ Для начала ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2011, 16:17 |
|
||
|
Проектирование БД для хранение электричских сетей
|
|||
|---|---|---|---|
|
#18+
virus_systemНУжно спроектировать бд для хранения электрических сетей. Сеть довольно разветвленная эл сеть. Если абстрагироваться, то щас храню сеть в виде графа. 1. Есть таблица объектов (узлы графа) tObj (id int, name varchar, typeObj int) 2. Есть таблица связей (связи графа) tRelation (id int, destpoint int, sourcepoint int, edge int) - edge - линия целиком - собираеться из relation Все как бы хранится, и грузиться, новот всякие рачсеты со схемой производятся довольно долго Например рачет Элемента питания (узла питания) - нужно от объекта бежать по всем его relation дальше от каждого relation к другому и так далее... Вот здесь возникает вопрос, есть ли какой нибудь более оптимальный способ хранения и "расчета" схемы? По поводу хранения и обработки деревьев и графов есть две книги: 1. Селко (в основном деревья, есть чуть-чуть о графах, возможно, о графах будет больше в новом издании 2012 года). 2. О деревьях и графах для SQL Server 2008 есть глава в книге Бен-Гана и др. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2011, 22:15 |
|
||
|
|

start [/forum/topic.php?fid=32&tid=1541886]: |
0ms |
get settings: |
4ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
149ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 207ms |
| total: | 436ms |

| 0 / 0 |
