Newsgroup: it.comp.software.database
Titolo: Progettazione

Vorrei un parere da voi.
La teoria dei database (l'algebra relazionale) insegna a creare db che siano
in forma normale, cosi capita talvolta che una tabella abbia 3 o più campi
chiave primaria e la cosa non è comoda da gestire.
Secondo me tutto questo andava bene nelle applicazioni a 2 livelli
(client/server) dove le forme normali (insieme ad altri vincoli di
integrita, validità, ec... ) garantivano che i dati che finivano nel db
fossero coerenti.
Oggi però le cose sono diverse, le applicazioni web ad esempio hanno tutta
la logica nello strato intermedio che si occupa di controllare e verificare
tutti dati che finiscono nel db.
Questo per dire che secondo me a volte conviene progettare database più
"leggeri" e spostare la logica che controlla i dati nel livello intermedio.
Questo ci porta ad avere dei db più facili da usare (soprattutto nella
applicazioni web dove a volte la chiave primaria deve "viaggiare" tra
diverse pagine) sacrificando la normalizzazione del db.
A me piace creare le tabelle con un unico campo chiave (ID) che quindi non
risultano sempre in forma normale.
Mi piacerebbe sapere cosa ne pensate e come progettate voi.
Ciao,
Emanuele

 tutti dati che finiscono nel db.
Se hai un DB che e' 'relazionale' perche' non lo usi ? Cosi' stai
sotto-utilizzando uno strumento e scrivendo codice 'n'-uplicato per 
gestirti coerenza dei dati che sarbbe meglio lasciar fare al database.
Davide

 Davide
Si OK lo sottoutilizzo per comodità.
Spesso per verificare che il valore da inserire nel sia compreso all'interno
di un certo range è più facile controllarlo prima di inserirlo.
Poi le relazioni e molte altre cose vanno comunque messe altrimenti invece
del db usiamo un file binario!!
emanuele

 di un certo range è più facile controllarlo prima di inserirlo.
No, e' meglio controllarlo PRIMA che l'utente possa selezionarlo. 
Se l'utente deve scegliere un'ID o altro che puo' essere solo all'interno
di un range di possibili valori, gli presenti una combo-box con i soli 
valori possibili (o altro sistema per 'forzare' il valore), non lo 
controlli DOPO che lui ti ha scritto una qualche 'azzata. Ma questo 
non fa' parte del database, fa' parte della progettazione di una 
interfaccia utente usabile.
Davide

 wrote in message
news:aatm6c$dn6c3$1...@ID-18487.news.dfncis.de...


 solo 1! campo chiave?
Se vuoi usare sempre e solo 1 campo chiave in alcuni casi ti tocca
usare un campo auto-incrementante o comunque aggiungere un campo
identificativo, il cui valore quindi non ha alcun riferimento con i
dati effettivamente inseriti. Problema uno: generare/reperire il campo
ID, problema due: non puoi usarlo per ricerche veloci perche' l'utente
non lo conosce/lo sa gestire, problema tre: rischi di avere 'n' record
tutti identici salvo l'ID.
Comunque, come detto prima, la de-normalizzazione e' una pratica
normale, viene fatta per migliorare le prestazioni del sistema, e deve
essere applicata ad ogni singolo caso "cum grano salis".
Davide

 ha scritto nel messaggio
news:aatpu8$dkrfu$1...@ID-18487.news.dfncis.de...

Mi intrometto per dire che sono completamente in accordo
con quanto detto Davide e aggiungo a proposito della denormalizzazione
che in Oracle esiste uno strumento: DISCOVERER che server a
inserire uno strato intermedio fra DBA e Utente.
Il database č organizzato per le Performance, Discoverer lo prepara
per facilitare l'accesso dei dati all'utente.
                                    danilo