Newsgroup: it.comp.software.database
Titolo: Database SQL e tabelle temporanee

Salve a tutti,
vorrei sottoporvi un quesito. Sparo secca la domanda, poi
in calce per chi volesse farsi un'idea piů precisa, illustro piů
dettagliatamente il problema.
E' sbagliato (o comunque, quali
controindicazioni puň avere) su database relazionali tipo SQL Server usare
delle tabelle temporanee create in automatico all'apertura dell'eseguibile
e distrutte in automatico alla chiusura del programma ?  
Lavoro in una
software house che produce un gestionale sviluppato in ambiente Delphi
utilizzando come base dati file DBF. Ora stiamo iniziando lo studio per
passare la base dati su Interbase. Siamo in fase di analisi dei problemi e
di ipotesi di soluzioni per valutare pregi e difetti di ciascuna soluzione.
In particolare ora ci siamo soffermati sul fatto che l'applicazione fa uso
abbondante di file temporanei (non criticateci per questa scelta non fatta
da noi...) generalmente contenenti un solo record, per memorizzare tutti i
dati esposti nelle form non legate direttamente ad una tabella (
p.es
. tutte
le form di ricerca). Questa logica non ci piace, ma modificarla implica una
revisione generale di tutta l'applicazione ed allora abbiamo elaborato una
soluzione alternativa. All'apertura della form (che usa il temporaneo),
creare sul database una tabella temporanea con nome univoco, ed alla
chiusura del form distruggerla. Questo significherebbe aggiungere solo due
istruzioni per ogni form. Una chiamata ad una UDF che crea la tabella ed
una chiamata ad una UDF che distrugge la tabella. Tecnicamente la soluzione
č fattibile, perň questa ci sembra una tecnica un po al di fuori degli
schemi e vorremmo se possibile capire quali problemi potrebbe darci.
Ringrazio anticipatamente tutti quelli che vorranno darci un consiglio.
Bruno
--------------------------------
Inviato via 
http://usenet.iol.it

 e distrutte in automatico alla chiusura del programma ?  
Tutto dipende dal tipo di gestione che il server ti consente di utilizzare
o implementa per default.
Solitamente, la creazione di una tabella comporta l'inserimento di
informazioni in una serie di tabelle interne che tengono traccia di
quali "oggetti" sono presenti nel database, poi viene allocato lo
spazio fisico per la gestione della tabella stessa. I dati che sono
inseriti vengono trattati come dati normali, quindi sottoposti a tutte
le operazioni di Log e Rollback necessarie.
Quando la tabella viene distrutta (drop), lo spazio fisico deve venire
rilasciato, questo puo' lasciare pero' dei "buchi" nei datafile che sono
usati dal database, a meno che tu non possa specificare per la
tabella temporanea uno specifico datafile.
Alcuni database (Oracle per esempio) hanno dei costrutti speciali che
ti consentono di creare delle tabelle definite come 'temporanee' su
dei datafile speciali che influiscono in maniera limitata sulle
operazioni di logging e che vengono distrutte automaticamente quando
la sessione viene rilasciata. Il vantaggio di questo tipo di gestione
e' che non si crea overhead di I/O perche' le operazioni non sono
soggette a logging, e che se il client crasha per qualunque motivo,
le tabelle sono comunque distrutte a cura del server.
Davide

o implementa per default.
Ok, quindi in sintesi, questa
tecnica potrebbe causarmi un appesantimento dell'applicazione e qualche
problema in più in caso di crash del programma (non credo che Interbase
abbia una gestione così sofisticata come Oracle, ma adesso cerco...).
Questi saranno gli estremi: una soluzione semplice ed economica ma poco
performante, ed una soluzione ben fatta ma più onerosa in termini di costi
di realizzazione. Non starà a me decidere, io devo solo prospettare
scenari...
Sei stato estremamente chiaro e preciso. Ti ringrazio.
