Помогите с SQL для хранимой процедуры...

← →
Nikolai_S © (2004-04-16 16:31) [0]

Доброго времени суток, уважаемые мастера!
Помогите составить хранимую процедуру на SQL Server 2000.

В БД есть таблица MY_TABLE(ID int, NAME nvarchar, PARAM_TABLE nvarchar), которая содержит список неких статистических показателей. Для каждого статистического показателя в БД имеется своя таблица, ее имя хранится в поле PARAM_TABLE.

Задача такова: необходимо написать хранимую процедуру, которая бы выдавала выборку с перечнем стат. показателей (из таблицы MY_TABLE) и содержала дополнительный столбец, в котором должно быть значение из соответствующей таблицы (имя которой хранится в поле PARAM_TABLE) для каждого стат. показателя.

← →
Курдль © (2004-04-16 16:42) [1]

> В БД есть таблица MY_TABLE(ID int, NAME nvarchar, PARAM_TABLE
> nvarchar), которая содержит список неких статистических
> показателей. Для каждого статистического показателя в БД
> имеется своя таблица, ее имя хранится в поле PARAM_TABLE.

Налицо грубая ошибка при проектировании БД.

← →
clickmaker © (2004-04-16 16:43) [2]

пробегись курсором по MY_TABLE, составь строку с selectом, а потом exec("<полученный селект>")

← →
Nikolai_S © (2004-04-16 16:51) [3]

> Курдль ©

Просвети, плиз, начинающего в чем ошибка и как надо

← →
ZrenBy © (2004-04-16 16:52) [4]

use pubs create table MY_TABLE (ID int, NAME nvarchar(100), PARAM_TABLE nvarchar(100)) insert into MY_TABLE select 1,"Показатель 1","master..syslogins" union all select 2,"Показатель 2","master..sysmessages" union all select 3,"Показатель 3","master..sysobjects" declare @S nvarchar(4000) set @S = N"select ID,NAME,PARAM_TABLE,A= case " select @S = @S+N"when PARAM_TABLE = """+PARAM_TABLE+N""" then (select count(*) from "+PARAM_TABLE+") " from my_table set @S = @S+N"end from my_table " exec sp_executesql @S drop table MY_TABLE

← →
Nikolai_S © (2004-04-16 17:04) [5]

> ZrenBy ©

Спасибо, этот пример работает как надо. Теперь вопрос: а будет ли работать (если да, то как быстро), если в таблице скажем 1000 записей? Ведь переменная @S не может быть безграничной

← →
serge35 (2004-04-16 17:12) [6]

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

← →
Курдль © (2004-04-16 17:13) [7]

> Просвети, плиз, начинающего в чем ошибка и как надо

Таблица MY_TABLE денормализована относительно таблиц, имена которых хранятся в ее поле PARAM_TABLE. Если Вы не прикалываетесь, а вправду не знаете основ реляционных БД, то приведу пример ошибки, которая Вас рано или поздно настигнет - из таблицы параметров запись давно удалили, а в MY_TABLE ссылка на нее осталась. Зато если правильно спроектировать БД, вполне можно обойтись без всяких процедур - одними запросами. Чаще всего процедура - роспись в собственном бессилии составить грамотный запрос.

Ну а если скажем стат.параметров может быть до нескольких тысяч. Если по ним все данные записать в одну таблицу, то SQL Server может просто не потянуть такой объем данных. Такие прецеденты уже были. Потому и приходиться разбивать на таблицы. В этом плане, говорят Oracle получше и побыстрее, но заказчик требовал SQL Server.

В таблице каждого стат. показателя может быть теоретически до нескольких сотен тысяч записей. Если взять и перемножить количество стат.показателей в таблице MY_TABLE на кол-во записей в каждой соответствующей таблице, то получим впечатляющий объем. Вставка и выборка данных при этом будет ужасно медленной. Я тестировал, мой вариант получился более быстрым.

Может быть в теории я и не прав, но в короткий срок мне нужно было сделать нетормозящее ПО, которое успешно создано и безошибочно работает.

← →
serge35 (2004-04-16 18:05) [9]

> Если по ним все данные записать в одну таблицу, то SQL Server может просто не потянуть такой объем данных

Бред какой-то.

> Вставка и выборка данных при этом будет ужасно медленной.

А как насчет индексов? Или это для "теоретиков"?

Помогите с SQL для хранимой процедуры... Найти похожие ветки