Ciao Ragazzi, ho un dubbio, se per ragioni progettuali volessi lavorare con un database non normalizzato, ad esempio con delle relazioni che da un lato sono 1..N e dall'altro sono 1...1 , sarebbe una cosa molto grave dal punto di vista delle funzionalità?
Ve lo chiedo perchè sto creando un db molto complesso, ma vorrei evitare di fare cagate... fatemi sapere. grazie ;D
Si vis Pacem Para Bellum
"Grave" in che senso? Se è ben gestito è pure meglio.Originariamente inviata da Lord112
Forse non hai chiaro il concetto di normalizzazione (3 sono le forme normali da attuare in un db).
La normalizzazione è un processo necessario per far sì che il db sia funzionale.
Ti invito a leggere un po' di teoria: http://www.mrwebmaster.it/sql/normal...se_7420_3.html.
Il mio SITO - http://vanex.altervista.org
Ritengo di avere "abbastanza bene" chiaro il concetto di normalizzazione, e le forme normali non sono 3 (sono parecchie di più).
Non è affatto un processo necessario per far sì che il db sia funzionale, anzi spesso si denormalizza per ottenere prestazioni nettamente superiori o funzionalità pressochè impossibili (o molto difficili).
Sono concetti che risalgono agli anni '70 e vengono ancor oggi insegnati come articolo di fede, ma al livello dei primi corsi universitari o giù di lì.
La differenza è tra chi non sa cosa sia un db normalizzato, e chi sa perchè lo è, perchè lo deve essere, quando può essere meglio non normalizzare, e come si gestisce un progetto "vero" con qualche centinaio di tabelle e qualche terabyte di dati, invece del progettino tipico della libreria o qualcosa del genere.
Poi ci vuole la consapevolezza della semantica del database, perchè normalizzare in maniera automatica significa spegnere il cervello (cioè applicando le regolette che vengono insegnate si perde di vista che a monte ci dovrebbe sempre essere la comprensione piena).
Altrimenti se scrivo questo semplicissimo esempio di studio (supponiamo siano fatture)
(progressivo,data,nome,indirizzo,imporot)
1,2015-06-06,pippo baudo,via roma 34, 100
2,2015-06-06,pippo baudo,via roma 34, 200
3,2015-06-06,mario rossi,via milano 12, 50
4,2015-06-06,mario rossi,via milano 12, 30
a qualcuno verrebbe in mente di normalizzare, dimostrando di non aver capito minimamente la teoria, che invece di essere riferita all'algebra o entità e relazioni, è riferita a problemi.
Mi riferivo all'utente che ha posto la domanda.
Nel tuo esempio? Avrei inserito un ID al posto del nome e tabellizzato il nome
1) evita ridondanza
2) risparmio di memoria
non credo sia un errore.
Tra l'altro le forme non sono molte di più...o se sì quali?!??! Ne conosco 5 la 4 e la 5 non necessarie per questo ne ho indicate 3 (le classiche che come dici si studiano).
Quindi secondo me non normalizzare non va bene ma con moderazione, forse questo volevi dire?.
Come fai a dire di non normalizzare?
ciao
Ultima modifica di VanessaInfo; 06-06-2015 a 14:37
Il mio SITO - http://vanex.altervista.org
a volte ridondare porta dei vantaggi. fa' conto, nell'esempio di prima, che tu fatturi a fronte di un documento di consegna, che è a fronte di un ordine di produzione che a sua volta è a fronte di un ordine cliente (ma possiamo complicarla ancora di più); spingendo agli estremi la normalizzazione, se volessi sapere con quale cliente ho fatto più fatturato dovrei coinvolgere tre-quatto tabelle con relative join; con un piccolo strappo alla regola (diciamo così) e cioè ridondando il cliente nella riga di fattura ottengo il risultato immediatamente, Ovvio, è una semplificazione, la cosa si può risolvere in mille modi diversi a seconda della situazione, ma era per rendere l'idea
1) avresti sbagliato, perchè la normalizzazione del cliente avrebbe fatto sì che nel momento in cui, ad esempio, cambia indirizzo, tutti i vecchi documenti avrebbero preso il NUOVO indirizzo.
Questo è il classico esempio di come NON comprendere la semantica del problema porta, applicando pedissequamente le regolette, a fare un disastro
2) per la normalizzazione francamente non ho molta voglia di fare il piccolo corso di basi di dati, vedo che stai già cominciando a scoprire che non sono 3
3) non ho mai asserito "non normalizzare"
Ho scritto, ed è cosa ben diversa, che non è NECESSARIO normalizzare (la domanda del post).
Aggiungo poi è NECESSARIO normalizzare BENE, cosa che non è affatto sinonimo (l'ho appena dimostrato con l'esempio classico precedente)
4) il "risparmio di memoria", ad esempio, non esiste proprio, poichè i database moderni utilizzano PAGINE di dimensione fissa (es. 4K, 16K, molto più raramente 64K), quindi paradossalmente finquando resti dentro una singola pagina non hai alcun beneficio nel senso di risparmio o meno di memoria. Così tanto per mostrare come un approccio scolastico sia lontano da uno concreto
5) sempre sotto questo profilo saprai benissimo che una macchina moderna, anzi un telefonino, può gestire database talmente immensi da essere fantascienza fino a pochissimi anni fa. E che un hard disk da 6terabyte ormai si trova per duecento euro nel negozietto sotto casa, sufficiente per memorizzare i dati di una multinazionale.
Quindi riassumendo è (altra metafora che ho letto, molto carina a mio avviso) come il freno a mano.
A scuola guida insegnano che serve come freno di stazionamento. Nelle corse di rally serve... per curvare.
Questo è vero (prestazioni).a volte ridondare porta dei vantaggi. fa' conto, nell'esempio di prima, che tu fatturi a fronte di un documento di consegna, che è a fronte di un ordine di produzione che a sua volta è a fronte di un ordine cliente (ma possiamo complicarla ancora di più
Tuttavia l'esempio è più radicale, cioè si sta usando qualcosa (normalizzazione) per memorizzare informazioni che NON devono essere normalizzate, il che avviene quando si "parte in 4a" senza curarsi di comprendere bene cosa si vuole ottenere.
Chi l'ha detto che i vecchi prendono il nuovo indirizzo?
Quel problema si risolve lato programmazione non lato db.
Quello che dice optime è vero come anche io avevo riportato, ad esempio se uno volesse essere proprio "scolastico" arriverebbe a smembrare i dati e dover fare il join di N tabelle per avere un dato, questo sì è esagerato...come dicevo con moderazione...e dopo attenta valutazione...
Tra l'altro non sai con chi parli e secondo te sto studiando ora... ("vedo che stai già cominciando a scoprire che non sono 3").
Io invece siccome non ti conosco e, nonostante la mia (poca) esperienza, penso che altri possano saperne più di me e quando non la pensano come me o (come nel tuo caso) mi dicono cose contrarie cerco di capire...non faccio il presuntuoso.
Il mio SITO - http://vanex.altervista.org
Lo dico io
Non direiQuel problema si risolve lato programmazione non lato db.
Siccome neppure tu mi conosci, linkarmi qualche guida per principianti ed asserire "forse non ti è chiaro..." quando direi che la situazione è opposta non è esattamente un modo gradevole di porsi.Io invece siccome non ti conosco e, nonostante la mia (poca) esperienza, penso che altri possano saperne più di me e quando non la pensano come me o (come nel tuo caso) mi dicono cose contrarie cerco di capire...non faccio il presuntuoso.
Certo sono consapevole che molto spesso s'insegna in modo dogmatico, come se in una certa situazione si debba sempre e comunque fare una certa cosa, senza preoccuparsi del perchè, o percome, o se ci sono altre strade, migliori o peggiore.
La normalizzazione è un esempio classico in cui si applica un metodo nato per risolvere un problema (memorizzazione dei dati su schede di carta perforate con buchini o nuclei in ferrite o quello che si usava) in un panorama informatico totalmente diverso rispetto a quello di oggi, e soprattutto sotto ipotesi rigorose che quasi mai vengono trattate (l'aspetto semantico).
Talvolta si trovano professori coi (...controxxi...) invece spiegano e precisano pregi e difetti, quando e come e perchè (io evidentemente son stato fortunato sotto questo profilo, mica ho avuto la scienza infusa).
L'esempino di sopra non è farina del mio sacco (anzi è una domanda con cui mi hanno aperto il deretano all'orale), ma è grandemente esplicativo di un esempio semplice e comprensibile dove la dipendenza funzionale SEMBRA essere eliminabile (algebricamente), ma non lo è (semanticamente).
Poi c'è tutto l'argomento delle prestazioni, che l'utente optime ha introdotto, e che senza dubbio ha un suo peso, anzi si potrebbe aggiungere anche il problema odierno di un database distribuito (ma non credo sia relativo alla domanda dell'utente, e quindi non vi ho accennato).
Torno quindi alla risposta iniziale: puoi fare benissimo un database denormalizzato che funziona perfettamente, anche meglio di uno normalizzato.
E viceversa, se vogliamo completare.
Ultima modifica di MySQL; 07-06-2015 a 12:55
Permessi di invio
Rispondi quotando