Tbella con più colonne o più tabelle con meno colonne ?

venerdì 09 gennaio 2009 - 15.47

bule Profilo | Junior Member

Ciao a tutti,
sembra uno scioglilingua ma ho questo quesito in fase di realizzazione della struttura di un database.

Tento di spiegarmi meglio:
pomiamo che io abbia la possibilità di strutturare il database nei due seguenti modi:

1) id - campo1_valore1 - campo1_valore2 - campo1_valore3 -...-campoN_valore1 - campoN_valore2 - campoN_valore3

2) tabella1: id - id_campo1 - id_campo2 -...-id_campoN
tabella2: id - id_campo su tabella1 - valore1 - valore2 - valore3


nel caso 1 avrei una lista molto lunga di colonne di tabelle in quanto avrei N campi ognuno dei quali ha diciamo M valori (nell'esempio 3)
nel caso 2 avrei due tabelle messe in relazione tramite l'uso della chiave esterna.

mi viene da dire che la seconda opzione sia più interessante ma cerco una conferma da chi sicuramente ne sa di più.

alx_81 Profilo | Guru

>Ciao a tutti,
Ciao!

>sembra uno scioglilingua ma ho questo quesito in fase di realizzazione
>della struttura di un database.
>
>mi viene da dire che la seconda opzione sia più interessante
>ma cerco una conferma da chi sicuramente ne sa di più.
Senza dubbio. Dovresti cercare di normalizzare il più possibile e quindi la seconda soluzione è quella da scegliere se non devi fare analisi, reportistica, storicizzazione.

Sono i fondamenti della normalizzazione dei database:
http://it.wikipedia.org/wiki/Normalizzazione_del_database
--

Alessandro Alpi | SQL Server MVP

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

bule Profilo | Junior Member

Grazie per la immediata risposta ...
ma non mi è chiaro perchè mi dici ok l'opzione numero 2, se non devi fare analisi, report etc ...? Forse perchè per metter insieme i dati devo ricorrere alle JOIN che magari potrebbero risultare lente ?

alx_81 Profilo | Guru

>Grazie per la immediata risposta ...
>ma non mi è chiaro perchè mi dici ok l'opzione numero 2, se non
>devi fare analisi, report etc ...? Forse perchè per metter insieme
>i dati devo ricorrere alle JOIN che magari potrebbero risultare lente ?
Considera che se devi fare analisi e usi strumenti come Analysis Services, questi ultimi lavorano meglio su basi dati denormalizzate, per ottenere degli schema particolari utili e ottimizzati per la navigazione, cosiddetta, multidimensionale. Quindi si scrivono dei veri e propri schema a stella (STAR SCHEMA) o degli schema a fiocchi di neve (SNOWFLAKE SCHEMA) che hanno delle DIMENSIONI (tabelline di dominio di contorno allo schema) e tabelle dei FATTI (ovvero quelli che contengono le MISURE, in forma denormalizzata).
Con questi schema si costruiscono i cosiddetti CUBI.. Ma non mi dilungo.
Se non si usano strumenti di analisi come quello descritto, ma si vogliono fare statistiche o query pesanti su dati storici (e quindi, a volte sono tanti) si preferisce creare già una struttura che sarà più vicina all'elenco dei report.

--

Alessandro Alpi | SQL Server MVP

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

bule Profilo | Junior Member

Ok grazie mille ... anche se dopo la tua dissertazione mi sono sentito un pò ignorante :-(

alx_81 Profilo | Guru

>Ok grazie mille ... anche se dopo la tua dissertazione mi sono
>sentito un pò ignorante :-(
Ma va.. te l'ho buttata lì perchè ci sarebbe da dire le cose mooolto meglio. E le conosco un pochino solo perchè ho dovuto lavorarci su..

--

Alessandro Alpi | SQL Server MVP

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org
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 !
Copyright © dotNetHell.it 2002-2025
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5