Perché una colonna in un database relazionale dovrebbe avere un unico scopo?

Question

Perché una colonna in un database relazionale dovrebbe avere un unico scopo?

#1 da (16 voti)
#2 da (1 voti)

0

Considera una tabella in cui una colonna rappresenta un valore monetario in alcuni casi e un link al valore di un altro record in altri casi in modo da avere il seguente:

TABLE 1
Id Product Composite
1  Apple   False
2  Orange  False
3  Pear    True

TABLE 2
Product  Date        Price 
1        2010-01-01  0.45
2        2010-01-01  0.50
3        2010-01-01  1.00
1        2010-01-02  0.46
2        2010-01-02  0.49
3        2010-01-02  2.00

Le tabelle sopra rappresentano il fatto che il prezzo di una Apple e di Orange viene indicato in ogni data dalla colonna corrispondente del Prezzo nella Tabella 2, in modo che il prezzo di una Apple nel 2010-01-01 sia 0.45 e il prezzo di una Orange è pari a 0,50 in quella stessa data, tuttavia, il prezzo per una pera del 2010-01-01 è 0,45 e il prezzo per una pera è 0,49 il giorno seguente, consentendo al prezzo della pera di essere determinato dal prezzo di una mela sul primo giorno e il prezzo di un Orange il secondo giorno.

Indicare i pro e i contro di questo approccio?

rdbms database-design normalization

posta ofraski 30.07.2013 - 04:52

fonte

2 risposte

1

Penso che la parola "scopo" esprima la domanda su un livello che è inutilmente astratto.

A un livello più semplice, possiamo dire che tutti i valori in una singola colonna devono essere ricavati dallo stesso dominio e avere la stessa semantica. Quindi lo stesso valore nella colonna in due righe diverse dovrebbe significare la stessa cosa.

In particolare, se i valori in una colonna sono chiavi esterne, dovrebbero essere tutte chiavi esterne alla stessa tabella. Ho visto l'opposto fatto, dove i riferimenti a più tabelle sono memorizzati in una singola colonna. Il risultato è invariabilmente un casino. Una colonna companion è sempre necessaria per disambiguare e questo porta a uno dei due problemi.

Ogni volta che la disambiguazione viene eseguita correttamente, il codice è più complicato di quanto dovrebbe essere, e viene eseguito anche più lentamente di quanto dovrebbe. E, naturalmente, se il programmatore dimentica di disambiguare correttamente un join, le cose sbagliate vengono unite. Ho visto entrambi i casi.

Le chiavi esterne sono il caso più ovvio, ma anche in altri casi la necessità di disambiguare è solo una conseguenza scomoda dell'introduzione dell'ambiguità in primo luogo. Se si mantengono dati diversi in colonne diverse, non è necessario disambiguare.

risposta data 02.08.2013 - 04:28

fonte

Leggi altre domande sui tag rdbms database-design normalization

Programmazione funzionale: confronta tutti gli elementi in una matrice Perché non ci sono parametri migliori dei pochi metodi di parametro?

score 16 · Accepted Answer

L'approccio è, francamente, orribile. A quanto ho capito, vuoi che la colonna "Prezzo" sia interpretata come una chiave esterna a Product.Id , quindi "reindirizza" la query per i prezzi delle pere a una query per i prezzi Apple o per i prezzi Orange. Ciò richiede una logica complicata nel codice SQL per quello che dovrebbe essere una semplice ricerca di tabelle, e poiché lo schema di base dati non ha campi di commento, è molto facile che qualcuno lo trascuri e presume semplicemente che il prezzo sia $ 1,00.

Ma a parte questo: non si salva nulla, né il tempo né lo spazio di archiviazione. Invece di abusare della colonna Price come chiave esterna, potresti semplicemente salvare il prezzo effettivo in quella colonna senza costi aggiuntivi! Si finirebbe con una tabella con valori duplicati, ma ciò è normale e previsto in un set di dati di grandi dimensioni.

Quindi, nel complesso, posso vedere solo i contro e non i pro qui.