nome tabella passato come parametro
nicoletta
DECLARE @nome_tabella CHAR(15);
SET @nome_tabella= "PIPPO";
create table @nome_tabella(
campo1 char(20),
campo2 int );
mi da il seguente errore
Messaggio 102, livello 15, stato 1, riga 11
Sintassi non corretta in prossimità di '@nome_tabella'.
Evidentemente il nome dela tabella deve essere indicato in chiaro e non
essere contenuto in una variabile (nome_tabella nella fattispecie)
il data base è composto da molte tabelle identiche come struttura.
Come fare a costruire delle query o delle stored procedure che
funzionino su tutte le tabelle senza scriverne tante quante sono le
tabelle e che differiscono solo per il nome di riferimento alla tabella?
grazie nicoletta
Giacomo Degli Esposti
[...]
> Evidentemente il nome dela tabella deve essere indicato in chiaro e non
> essere contenuto in una variabile (nome_tabella nella fattispecie)
Esatto. Purtroppo in SQL e' possibile avere parametri solo per indicare
dei valori, non degli oggetti di database.
> il data base è composto da molte tabelle identiche come struttura.
> Come fare a costruire delle query o delle stored procedure che
> funzionino su tutte le tabelle senza scriverne tante quante sono le
> tabelle e che differiscono solo per il nome di riferimento alla tabella?
> grazie nicoletta
Dipende dal database che stai usando (informazione che hai dimenticato
di fornirci :)
In generale l'unico approccio e' di sfruttare eventuali
comandi/istruzioni che interpretano un valore stringa come un comando e
lo eseguano.
Ad esempio, in MSSQL potresti fare qualcosa del genere:
--non testato
select @table = 'miatabella', @campo = 'codice'
select @sql = 'select * from ' + @table + ' order by ' + @campo
execute(@sql)
ciao
Giacomo
nicoletta
> Dipende dal database che stai usando (informazione che hai dimenticato
> di fornirci :)
hai perfettamente ragioe si tratta di SQL SERVER 2005
> In generale l'unico approccio e' di sfruttare eventuali
> comandi/istruzioni che interpretano un valore stringa come un comando e
> lo eseguano.
> Ad esempio, in MSSQL potresti
e con questa scelta in termini di velocità di esecuzione delle query
come se la cava SQL SERVER???
grazie nicoletta
Giacomo Degli Esposti
>> In generale l'unico approccio e' di sfruttare eventuali
>> comandi/istruzioni che interpretano un valore stringa come un comando
>> e lo eseguano.
>> Ad esempio, in MSSQL potresti
> e con questa scelta in termini di velocità di esecuzione delle query
> come se la cava SQL SERVER???
Piuttosto male, perche' deve ricompilare l'istruzione ogni volta che
esegue la tua execute con una stringa diversa.
Altro approccio possibile e' creare delle stored procedure, magari
generando il codice dinamicamente, ma bisognerebbe capire meglio cosa
stai cercando di fare.
ciao
Giacomo
nicoletta
> Altro approccio possibile e' creare delle stored procedure, magari
> generando il codice dinamicamente,
Si è quello che tuttora faccio, valutavo se esisteva un'altra strada.
> ma bisognerebbe capire meglio cosa
> stai cercando di fare.
E' abbastanza semplice, il mio database possiede una 50 di tabelle
composte da 8 campi tutti int
quindi ogni volta che devo fare delle query devo scrivere
SELECT * FROM tabella1 WHERE .....
oppure
SELECT * FROM tabella2 WHERE .....
spero di essere stata chiara.
ciao e grazie da nicoletta
The man with two watches
> il data base è composto da molte tabelle identiche come struttura.
Non si puo' ovviare e farne solo una? Il POOD ne sarebbe contento.
Oppure con una View?
nicoletta
>> il data base è composto da molte tabelle identiche come struttura.
>
> Non si puo' ovviare e farne solo una?
capire quale delle due strade (questa e la generazione da codice della
query sia più performante.
>Il POOD ne sarebbe contento.
> POOD non ne conosco il significato?
nicoletta
The man with two watches
>>> il data base è composto da molte tabelle identiche come struttura.
>>
>> Non si puo' ovviare e farne solo una?
> Si, si potrebbe ma questo comporta altri problemi, sto cercando
> di capire quale delle due strade (questa e la generazione da
> codice della query sia più performante.
Se non c'e` un motivo convincente per la divisione in varie tabelle,
calcola che di per se' (o meglio, a parita` di tutti gli altri
fattori), probabilmente la tabella unica sara` almeno uguale,
se non piu` veloce, grazie al lavoro piu` semplificato del dbms.
Se non altro, l'amministrazione e la scrittura di codice sara`
molto piu` semplice.
La generazione di codice a run-time comporta ogni volta la
generazione di un nuovo query plan (oppure il riuso di uno
gia` presente nella cache se l'optimizer e` bravo), che in ogni
caso e` una operazione un po' onerosa, ed avra` una sua incidenza
sul tempo totale di query se fatta molto spesso (indispensabile
controllare il profiler e il query plan).
>> Il POOD ne sarebbe contento.
> POOD non ne conosco il significato?
Ladies and Gentlemen, permettetemi di presentarvi "The Principle
of Orthogonal Design", POOD per gli amici.
In breve, come la normalizzazione si occupa di evitare
le anomalie all'interno della stessa tabella, cosi` il POOD le
evita tra tabelle diverse.
Una delle cose che dice e` che quando due tabelle hanno lo stesso
header, allora c'e` un errore. E' infatti probabile che il nome
della tabella contenga un dato, che invece dovrebbe stare in una
colonna; esempi tipici:
Vendite2007 {Cliente, importo}
Vendite2008 {Cliente, importo}
Vendite2009 {Cliente, importo}
ClientiItalia {Nome, Settore}
ClientiFrancia {Nome, Settore}
ClientiGermania {Nome, Settore}
...dovrebbero diventare:
Vendite {Cliente, Importo, Anno}
Clienti {Nome, Settore, Stato}
Questo ha molte conseguenze, una delle quali e` che ora il dbms ha
un'informazione in piu` su cui basare le proprie scelte.
Esempio: prova a immaginare una view che unisce le 50 tabelle;
prova a ipotizzare una INSERT; come potrebbe il dbms sapere in
quale tabella inserire la riga?
L'applicazione del POOD mi fa specificare l'attributo necessario a
rendere la view modificabile (uno dei problemi dei dbms, ma non
della teoria relazionale).
bye
nicoletta
Potrebbe essere interessante..
ciao nicoletta