Привет.
Почитал тут уже достаточно топиков на эту тему, и хоть говорят что это велосипед и полно готовых решений(та же ИСКРА) все таки решился писать.

Во первых меня впечатлила ИСКРА... и порадовала тем что, я хоть и начинающий программист, но сам дошел до тех задач которые реализованы в ИСКРЕ. Мне конечно же не нужна настолько мощная и гибкая система, но некоторые ее фичи хотелось бы реализовать.

Итак мое ТЗ(верней часть): есть несколько БД разбросанных по сети организации. Нужно уметь взаимодействовать(читать\писать) с любой из них. Процесс взаимодействия (в дальнейшем "Процесс") абсолютно произвольный, это может быть работа с одно БД, двумя... независимо, или в зависимости от результатов работы с предыдущей БД.

Дальше идут мои рассуждения, которые возможно ошибочны и я надеюсь что вы мне подскажите верное направление.
Я полагаю что результатом декомпозиции Процесса(P) являются запросы(Q) осуществляемые либо последовательно, либо параллельно(условно).

То есть Q - неделимая частица из набора которых строится процесс. При этом запросы могут быть двух типов - возвращающие "набор" значений и не возвращающие.

Введем такой синтаксис:

Q1(DB1)[]: NULL - запрос Q1 без входящих переменных(условий) в базу DB1 не возвращающий ничего.
Q2(DB1)[A]: NULL - запрос Q2 с входящей переменной(условий) A в базу DB1 не возвращающий ничего.
Q3(DB1)[]: R(A,B,C) - запрос Q3 в базу DB1 возвращающий одну запись (A,B,C)
Q4(DB1)[K]: T(A,B,C) - запрос Q4 в базу DB2 с входящей переменной(условий) K возвращающий таблицу (A,B,C)

Тогда процессы могут выглядеть так:
P1: Q1(DB1)[] - просто выполнить запрос Q1
P2: Q1(DB1)[] + Q2(DB1)[A] - выполнить последовательно Q1 b Q2.(В одну и туже базу данных!!)
P3) Q5(DB2)[ Q6(DB1)[]:P ] - выполнить запрос Q6 и на базе его результата P выполнить запрос Q5(В разные базы данных!!)

Вообщем тут можно придумать массу процессов, но думаю суть я передал.

Вопросы которые меня мучат:
1) Как разработать базу данных для хранения процессов, запросов и их взаимодействия чтоб потом не наступить на грабли.
2) Как осуществлять взаимодействие между запросами в разные БД, то есть как лучше хранить результат.

AlexandrPlus
1) "процессы" будут храниться в БД в виде процедур, функций, а запросы в виде вью,
а взаимодействие - это что будет написано в процедурах-функциях, вью


1) Не всегда можно хранить свои процедуры и вью в чужих БД. Но допустим что даже можно хранить. Не всегда разные инстансы SQL Server-a залинкованы.

Вообще меня больше волнует как спроектировать именно взаимодействие. То есть модель данных которая бы описывала набор запросов, их последовательность, зависимости входяших и исходяших переменных. Когда мы находимся в рамках одного инстанса SQL Server-a то все эти вопросы не встают, но что делать когда инстансы разные(и не обязательно линкованные).

Если можно, подскажите что то в этом направлении?

rokstarArikKh,

Что является результатом взаимодействия запросов (а правильно - результирующих данных) из разных БД? некий сводный набор данных для анализа? или же вы хотите еще и логику на это навесить?

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

Объекты отображения в свою очередь могут вызывать запросы.