Devo strutturare i miei DB basandomi sul vero formato dei dati, o su come intendo utilizzare tali dati?

1

Questa è per lo più una domanda ipotetica, ma è qualcosa che ho gettato attorno e mi sono chiesto che cosa facciano gli altri. Ecco un esempio forzato per illustrare: Diciamo che sto costruendo un'app che consente agli utenti di scegliere alcune parole chiave e quindi mostra loro le foto che sono contrassegnate con tali parole chiave.

Da un lato, ho potuto creare user , keyword e photo tabelle che memorizzano le entità di dati così come esistono. Ciò consentirebbe di modificare facilmente la funzione dell'app senza dover modificare le strutture di dati sottostanti, ma richiede anche diverse query per recuperare i dati necessari per l'app.

Oppure potrei avere una sola tabella user-photos e in qualche modo inserire tutti i dati in essa contenuti. Ciò renderebbe più semplice l'estrazione dei dati necessari per l'app, ma sarebbe più difficile eseguire qualsiasi altro tipo di query su tali dati. Dopo tutto, un user-photo non è realmente una cosa - è solo una comoda struttura dati per questo scopo.

Questo potrebbe essere un cattivo esempio, ma la spinta principale della mia domanda è la seguente: se la struttura del tuo database si basa sulle reali entità sottostanti che stanno memorizzando, o puoi usare scorciatoie per rendere più facile l'uso dei dati per il tuo scopi?

    
posta Hartley Brody 03.11.2011 - 01:04
fonte

3 risposte

3

Stai chiedendo se devi normalizzare (dividere in tre tabelle) o de-normalizzare. Hai già capito alcuni dei pro e dei contro di entrambi. Nella maggior parte dei casi, è preferibile andare con un livello più alto di normalizzazione. Ciò consente ai tuoi dati di rappresentare più da vicino le entità con cui hai a che fare, e in generale questo renderà la vita più facile.

Nel tuo caso, ti consiglio la prima opzione (anche se potresti trovare che necessiterà di qualche ritocco, ad esempio: la relazione tra foto e parole chiave è molti-a-molti, quindi potresti volere un photos-keywords per archiviarli relazioni). Puoi ancora ottenere la nozione di user-photo con una query o una vista sulle tre tabelle sottostanti.

Le situazioni in cui la denormalizzazione potrebbe essere migliore di solito si verificano nei sistemi di segnalazione.

Per ulteriori informazioni:

Normalizzazione: link

Denormalizzazione: link

    
risposta data 03.11.2011 - 01:09
fonte
1

Vado sempre con un progetto di database normalizzato. Un vantaggio del design normalizzato del database è che la normalizzazione consente di estendere il database senza rielaborarlo nella maggior parte dei casi (devo ancora dimostrare questa idea ...).

Nel tuo caso:

Il design proposto

user, keyword and photo

non è valido. Questo perché la relazione tra un utente e una parola chiave è una relazione molti-a-molti.

anche

user - photo

non è valido, dove memorizzeresti le parole chiave e come ti relazioneresti agli utenti se lo fai?

This would make it easier to pull the data I need for the app

Non preoccuparti della lettura dei dati. È solo questione di alcuni SQL che ti richiederebbero poche ore o meno per costruire e ottimizzare.

    
risposta data 03.11.2011 - 01:15
fonte
1

Ciò di cui parli a volte viene definito come la differenza tra i database OLTP e OLAP . L'unica lettera che differisce è il T / A:

  • T = Transazionale
  • A = Analitico

I database OLTP sono ottimizzati per i dati che vengono modificati continuamente. Ciò in genere implica che sia normalizzato.

I database OLAP sono ottimizzati per la segnalazione. Di solito sono de-normalizzati, qualcosa come una configurazione di tabella "stella".

Normalmente i database OLTP sono i database di produzione che eseguono dati di raccolta per tutto il giorno, quindi esiste un tipo di processo che preleva i dati dal database OLTP e lo riformatta nel database OLAP a intervalli regolari (di notte, ad esempio ). Ciò significa che alcune persone sedute alla loro scrivania con rapporti storici non possono vedere nulla dopo la scorsa notte, ma ottengono prestazioni migliori.

Ciò significa che se hai iniziato a costruire la tua applicazione includendo un database OLAP per i tuoi rapporti, è probabilmente un caso di ottimizzazione prematura. È necessario il database OLTP per eseguire l'applicazione e OLAP è un'ottimizzazione per migliorare le prestazioni. Pertanto, l'approccio corretto è iniziare progettando un database normalizzato (nel tuo caso tabelle separate per ogni "entità").

    
risposta data 03.11.2011 - 01:41
fonte

Leggi altre domande sui tag