Newsgroup: it.comp.software.database
Titolo: Problema con i CAP

Ciao a tutti, posto nel newsgroup in quanto spero che altri abbiamo avuto
il mio stesso problema, ho un elenco di contatti con nome, cognome,
indirizzo, cap....
io avevo pensato: recupero l'elenco dei cap e poi completo l'elenco
inserendo località, provincia, regione ....
problema:
ho scoperto che i cap non sono univoci, quindi allo stesso cap possono
corrispondere diversi paesi/località
come posso risolvere il mio problema? recuperare la località corretta
basandomi sul CAP??
Grazie mille!


Ti sei risposto da solo, non puoi (almeno basandoti sul cap).
Soluzione
Nome Cognome Indirizzo FkCitta
Dove FkCitta è chiave esterna per la tabella Citta.
Ciao
Stefano 

 basandomi sul CAP??
Facendola scegliere all'utente?

 inserendo località, provincia, regione ....
Problema sempre interessante quello delle anagrafiche, perché di
solito si hanno varie dipendenze funzionali all'interno della stessa
tabella senza accorgersene. Una dipendenza funzionale è un'indicazione
che si hanno due entità nella stessa tabella, ossia una fusione di più
tabelle.
Di solito finisce che uno non normalizza completamente le tabelle
perché alla fine si rompe le scatole :-)
Per cui bisognerebbe iniziare a chiederti le specifiche concettuali
complete, senza le quali nulla si può dire sulla correttezza formale
dello schema di database.
O più semplicemente: di quanta "potenza di fuoco" hai bisogno?
Stai eseguendo un'accurata analisi geo-demoscopica, oppure il db servirà
solo per stampare indirizzi sulle buste al momento di spedire le
fatture?
Nel secondo caso, fai tutto in una tabella e vivi felice :-)
Se invece vuoi aprire il Vaso di Pandora, ti preavviso che le tabelle
fioccano numerose assai.

 basandomi sul CAP??
Allora, intanto il discorso e` piu` complesso di quanto ricordavo, in
quanto l'univocita` non e` data da CAP/citta`, ma da CAP/citta`/zona (vedi
ad esempio Roma che, oltre ad un CAP generico, ha anche dei CAP specifici
per alcune strade). Una chiave del genere, quindi, non e` riproducibile
tramite una referenziazione uno a molti. La soluzione, quindi, a livello
di db e` mettere un ID come chiave primaria e, a livello applicativo,
mettere un form di ricerca del CAP richiesto. Per farti un esempio, eccoti
un record che popolava la tabella da me creata:
INSERT INTO LK_COMUNE (ID_COMUNE, CAP_COMUNE, SIGLA_PROVINCIA,
                       NOME_COMUNE, ZONA_CAP_COMUNE)
                VALUES('61467', '00138', 'RM', 'ROMA',
                       'GAIOLE IN CHIANTI (VIA)');
A tal proposito, mi e` ritornato in mente un aneddoto di quando creai una
tabella dei CAP. Praticamente, per l'applicativo che sviluppai, ho creato
una struttura anagrafica del genere:
Comune (con CAP)
  Provincia
    Regione
      Nazione
Un mio collega lamento` il fatto che, secondo lui, una anagrafica del
genere era strutturata in maniera errata, proprio a causa del CAP.
Perche`? Cos'ha che non va una anagrafica del genere? L'unica
particolarita` di tale anagrafica, e` che le colonne significative
(SIGLA_PROVINCIA, SIGLA_REGIONE e SIGLA_NAZIONE) non erano chiavi primarie
della tabella, ma chiavi univoche (la chiave primaria era l'ID[1])
Henryx
[1] si, lo so che e` terribile, ma allora non ero abbastanza pratico di
queste cose (ovvero: mettevo un ID numerico praticamente in tutte le
tabelle)
-- 
 Signore e signori! Lo avete letto sui giornali! E ora fremerete d'orrore 
 osservando con i vostri stessi occhi il piu` raro e tragico degli 
 scherzi di natura! .. l'uomo medio! 
                                     Joker (Batman: the killing joke)