normalizzazione dei database - quanto in profondità dovrei collegare le tabelle insieme?

Question

Ho tre tabelle: Post, allegati, e Media.

Messaggi con allegati, e gli allegati hanno Media.

Al momento, la Posta e le tabelle degli allegati sono collegate da chiavi esterne, e così sono l'Attaccamento e tabelle Media. La mia domanda è, per il bene di una corretta progettazione di database e la normalizzazione, mettermi a configurare una relazione di chiave esterna tra la Posta e Media? Non sono sicuro di come dovrei profonda collegare questi tavoli insieme.

Grazie

Answer 1

per il bene di una corretta progettazione di database e la normalizzazione, mettermi a configurare una relazione di chiave esterna tra la Posta e Media?

Per "corretta normalizzazione" si deve assicurare che non ci sono "anomalie Update".

Se qualcuno aggiorna un post, cosa succede alla Allegati e Media? Sarà rinominare un post scollegare gli allegati e / o dei media? Se è così allora la vostra FK è sbagliato. [Suggerimento, è necessario utilizzare chiavi surrogate non il nome del post per fare il lavoro della tua FK.]

Se qualcuno vuole "spostare" un allegato da un messaggio ad un altro [cioè, aggiornare riferimento FK del allegato], che cosa succede al Media? Ha rimanere con il collegamento e passare alla nuova Post?

Potrebbe finire con post con allegati e dei media, così come allegati avere Media? Può la Post e gli allegati in disaccordo circa la media, perché l'allegato è stato "spostato", ma l'articolo non è stato anche aggiornato?

Se è possibile avere contraddizioni, avete rotto seconda forma normale e hai ripetuto le relazioni chiave non avresti dovuto ripetuti.

Una corretta normalizzazione è facile.

dati dipende dalla chiave e nient'altro che la chiave.

Non copiare o ripetere le dipendenze da nessuna parte. Quello che stai chiamando "deep linking" sembra essere una ripetizione delle dipendenze.

Answer 2

No, per la normalizzazione profondo come 3NF concerne la vostra, che è la solita normalizzazione livello, la struttura è ok.

Per la normalizzazione record ha costa nonché avvantaggia, specialmente per l'inserimento dei dati e cancellazione contro un importante livello di controllo sulla precisione come e ciò che può essere inserito.

Un normalizzati e denormalizes a suo rischio e pericolo:)

Answer 3

Credo che tu sei OK.

Sembra possibile che un POST può avere diversi allegati e che un allegato può avere diversi posti, in tal caso è necessario un ente di collegamento per la terza forma normale:

  Post

    |
    |
  -----
  | | |

Post_Attachment

  | | |
  -----
    | 
    |

Attachment

    |
    |
  -----
  | | |

  Media

Ma dalla tua descrizione non sembra esserci alcuna relazione fondamentale tra POST e MEDIA.

Answer 4

L'unico motivo per l'aggiunta di un FK da Media a Post sarebbe se avete bisogno di filtrare o selezionare il supporto per un particolare post senza riguardo per gli allegati. Anche se avete bisogno di visualizzare i media (forse per tipo) e il post a cui appartiene, non vorrei aggiungere un'associazione diretta; l'overhead per l'aggiunta di un secondo join (tramite la tabella allegato) è probabile che sia il minimo, quindi è improbabile che vedere alcun miglioramento significativo.

Answer 5

tabelle di collegamento profondo come un senso. Denormalizzare per la segnalazione e dopo aver visto i problemi di prestazioni.

Answer 6

Prima di tutto, non c'è bisogno di usare chiavi surrogate. Un database corretta sarà a cascata gli aggiornamenti, se volete. Quando normalizzare un database, si sta di solito cercando di ottenere 3 ° forma normale o addirittura BCNF. 2 ° forma normale non sarà sempre proteggere i dati da anomalie di aggiornamento. Determinazione delle dipendenze funzionali nello schema dovrebbe essere semplice una volta che si produce un diagramma ER e decidere quali dati fa parte delle entità (messaggi, allegati, Media) e quali dati è parte delle relazioni. A seconda della cardinalità dei vostri rapporti, si può o potrebbe non essere necessario unire le tabelle. La cosa migliore da fare è quello di modellare i dati in un diagramma, poi trattare con i problemi di attuazione.