[SQL 05] Chiarimento su progettazione db e query

martedì 04 novembre 2008 - 14.15

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Devil Profilo | Junior Member

109 messaggi | Data Invio: mar 4 nov 2008 - 14:15

ciao a tutti,
da una discussione su un'altra stanza del forum per un problema in ASP ho riscontrato un'anomalia nel mio modo di progettare db, che , di conseguenza, mi crea qualche grattacapo.
Chiedo allora a voi qualche delucidazione:

Faccio un semplice esempio.
Ipotizziamo di avere una tabelle persone così costruita

TPersone
-----------
idPersona (PK)
nome
descrizioneAttivita (FK)

Una persona ha un'attività, e quindi creo una tabella che mi contenga un elenco di attività. La tabella attività, mi avevano spiegato a scuola, si può realizzare così

TTipiAttività
------------------------------
descrizioneAttivita (PK)

in quanto gli id numerici servivano esclusivamente anni fa per limitare lo spazio occupato in memoria.Quindi così le ho sempre realizzate in tal modo.

Le due tabelle vengono poi messe in relazione molti-1

Ma altre persone mi hanno detto che è corretto invece realizzarle in quest'altro modo.

TPersone
-----------
idPersona (PK)
nome
idAttivita(FK)

TTipiAttività
-------------
idAttivita (PK)
descrizioneAttivita

e posso anche essere d'accordo. Secondo voi qual è il metodo corretto?

Il dubbio che poi mi nasce di conseguenza è come inserire i valori nella tabella TPersone.Mi spego meglio:
Nel mio caso (il primo) nella tabella TTIpiAttività avrei inserito diversi record per ottenere un risultato tipo questo

TTipiAttivita
----------------
Operaio
Impiegato
Capo reparto
Direttore
----------------

e poi per l'altra tabella semplicemente avrei scritto---> INSERT TPersone (nome,descrizioneAttivita ) VALUES (Mario,Operaio)

e tutto funziona.

Nel secondo caso invece non devo inserire il valore "Operaio" ma bensì il suo id!!...come la scrivo la query in questo caso?
devo fare una select annidata perchè mi restituisca l'id corrispondente all'attività di "Operaio"?

Se avessi più tabelle relazionate la insert diventerebbe allora molto complessa...

é così che si fa o sbaglio?

Grazie anticipatamente per qualsiasi chiarimento in merito.

Ciao

lbenaglia Profilo | Guru

5.625 messaggi | Data Invio: mar 4 nov 2008 - 14:29

>TTipiAttività
>------------------------------
>descrizioneAttivita (PK)
>
>
>in quanto gli id numerici servivano esclusivamente anni fa per
>limitare lo spazio occupato in memoria.Quindi così le ho sempre
>realizzate in tal modo.

Ciao Diego,

Ti assicuro che servono anche oggi se non vuoi avere indici mastodontici ed inefficienti

>Ma altre persone mi hanno detto che è corretto invece realizzarle
>in quest'altro modo.
>
>TPersone
>-----------
>idPersona (PK)
>nome
>idAttivita(FK)
>
>
>TTipiAttività
>-------------
>idAttivita (PK)
>descrizioneAttivita
>
>e posso anche essere d'accordo. Secondo voi qual è il metodo
>corretto?
Questo.

Relazione 1 a molti tra TTipiAttività e TPersone (1 attività può essere svolta da 0, 1 o molte persone e 1 persona svolge 1 sola attività) utilizzando colonne numeriche (piccole ed efficienti) per definire un constraint di FK sulla tabella TPersone.
Ricordati di definire un indice nonclustered sulla FK (tabella TPersone colonna idAttivita).

>Nel secondo caso invece non devo inserire il valore "Operaio"
>ma bensì il suo id!!...come la scrivo la query in questo caso?
>devo fare una select annidata perchè mi restituisca l'id corrispondente
>all'attività di "Operaio"?
Scusa, ma perché lato applicativo non carichi ad esempio una lista o una combo sia con la chiave che con la descrizione?
Quando l'utente seleziona "Operaio" recupererai la sua chiave dal controllo stesso (non chiedermi la proprietà esatta perché sono anni che non sviluppo

) e provvederai a passarla come parametro di input alla stored procedure preposta all'inserimento della riga nella tabella TPersone.

>Grazie anticipatamente per qualsiasi chiarimento in merito.
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

Devil Profilo | Junior Member

109 messaggi | Data Invio: mar 4 nov 2008 - 14:52

Ciao,
bene, allora mi sa che che a scuola potevano spiegare meglio le cose...

Comunque sia d'ora in poi si lavora nel 2° modo.
Solo una spiegazione su
"Ricordati di definire un indice nonclustered sulla FK (tabella TPersone colonna idAttivita)."
se puoi,che non ho ben capito da ciò che ho letto in rete.

Per il discorso query è giusto quello che mi dici, da applicazione la cosa risulta facile.(almeno così penso, devo ancora provarci)
Il mio problema nasce però perchè devo importare una grossa quantità di dati dati da uno o più file di excel a scelta dell'utente.
Immagina che quello di seguito sia il file excel.

|Paolo__|Operaio___|
--------------------------
|Antonio|Impiegato_|
--------------------------
|Carlo__|Direttore__|

Per caricare questi dati nella tabella uso una query che compongo attraverso codice VBA per indicare i valori da inserire, ma mentre prima riuscivo a realizzarla agevolmente adesso non so come scrivere la sintassi!!!

Riesci a scriverla per questo semplice esempio? (poi io lo adatto alla mia realtà)

Grazie ciao

lbenaglia Profilo | Guru

5.625 messaggi | Data Invio: mar 4 nov 2008 - 15:04

>bene, allora mi sa che che a scuola potevano spiegare meglio
>le cose...
Spesso chi le isegna, non le ha mai sperimentate in progetti reali...

>"Ricordati di definire un indice nonclustered sulla FK (tabella
>TPersone colonna idAttivita)."
>se puoi,che non ho ben capito da ciò che ho letto in rete.
Quando definisci un constraint PRIMARY KEY, praticamente tutti i DBMS definiscono un indice univoco NOT NULL sulla colonna (o insieme di colonne); quando definisci un constraint FOREIGN KEY non viene definito alcun indice (dato che non serve a niente ai fini di garantire l'integrità referenziale tra le due tabelle relazionate), però con molta Probabilità andrai ad eseguire una JOIN tra le due tabelle, quindi risulta estremamente utile definire un indice sulla colonna (o colonne) della FOREIGN KEY in modo da evitare un full scan della tabella.

>Il mio problema nasce però perchè devo importare una grossa quantità
>di dati dati da uno o più file di excel a scelta dell'utente.
Io importerei l'intero file Excel in una tabella di appoggio, andrei a popolare la tabella della attività con quelle mancanti e poi farei una JOIN tra la tabella di appoggio e quella delle attività sulla descrizione per recuperare l'ID e procederei all'INSERT delle Persone tramite una INSERT...SELECT.

>Grazie ciao
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

Devil Profilo | Junior Member

109 messaggi | Data Invio: mar 4 nov 2008 - 15:11

ok, ora per il discorso db la cosa è più chiara.

Per il secondo invece devo rifletterci perchè il file è un pò complesso ma potrebbe essere fattibile la tua idea...devo provare e se ci sono problemi...... ti farò sapere!

Grazie ancora ciao alla prossima

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !