Добрый день.

>>>>
Я думаю Вам легче всего создать свою нормализованную структуру, без всякого множества таблиц, и перекачивать в нее данные, раз те таблицы со сторонних организаций и менять их нельзя. Уверен, что как только Вы это сделаете, у Вас отпадут все вопросы как сделать ХП и скорее всего достаточно будет написать не очень даже сложный запрос, чтобы получить требуемое.
>>>>

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

>>>
Если у вашей "сторонней организации" с каждым новым видом изделия плодятся таблицы, это не значит, что ВАШИ таблицы, продуманные, нормализованные и расчитанные на более или менее общий случай, должны плодиться тоже - они останутся такими же.

Да, я это понимаю.

>> Да, скорее всего придется писать программку, которая "данные сторонней организации" будет конвертировать в данные для вашей базы.

Это тоже я понимаю. Когда должна осуществляться конвертация ? С учетом того, что данные "сторонней организации" изменяются ежедневно и они нам про это не сообщают и мы производим расчетнесколько раз в день, то наверное это должно осуществляться непосредственно перед расчетом. Так ?

Раньше эта организация поставляла нам данные в dbf, сооттветственно у меня написано приложение которое осуществляет расчет описанным мною выше методом. Теперь эта организация выложила все данные на SQL сервер. Так как это уже клиент серверная технология мне хочется не просто брать данные из другого источника, но и УСКОРИТЬ ВРЕМЯ РАСЧЕТА за счет использования возможностей SQL сервера.

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

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

Вовсе нет. Сейчас я смотрю какие у меня изделия в плане, смотрю какие таблички соответствуют этим базам данных, и в процессе расчета выбираю данные из этих табличек.

То что делалось просто на клиенте, а именно

1) получение списка необходимых таблиц
2) непосредственно работа с этими таблицами

на SQL вызывает у меня затруднения.

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

Надеюсь я все понятно излагаю

Благодарю за внимание.

>> А как "в жизни" (опишите, пожалуйста, алгоритм) по таблице с "новым видом изделия" можно определить методику расчета?

Методика расчета остается та же. Просто в запрос попадает еще одна таблица.

>> Почему вы считаете, что процесс расчета должен происходить ИМЕННО В ХРАНИМОЙ ПРОЦЕДУРЕ НА SQL СЕРВЕРЕ?

Я так не считаю. Я это пытаюсь выяснить. Ответ, что данная вещь на SQL сложно реализуется - является тоже ответом, и является аргументом, чтобы оставить логику на клиенте, что я похоже и сделаю.

>> Более того, концепция n-уровнего приложения так и требует - никакой бизнес логики в самой базе данных, вся бизнес логика заключена в приложении. Смотрите на базу данных просто как на хранилище данных, а не аппарат реализующий в себе бизнес-логику. И база получится проще (без завернутых хранимых процедур), и приложение лучше (аккуратное разделение полномочий между подсистемами, удобтсво в обслуживании и модификации, т.д.).

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


И на последок. Для повышения уровня знаний:

Если я одним запросом получил список таблиц:

select TableNames from AllTables where TableNeeded = 1

могу ли я выполнить следующий запрос:

select * from Table1
union
select * from Table2
union
.....
union
select * from Tablen

где Table1..Table2 - берутся из первого запроса ?

>> Выполнить то запрос можно, но посредством динамического SQL. То есть на первый запрос организовать курсор, в цикле этого курсора построить строку скрипта, а потом уже выполнить.

Спасибо. А нельзя ли посмотреть пример скрипта ?