DB Schema design: singola tabella con più colonne vs più tabelle con meno colonne

Question

DB Schema design: singola tabella con più colonne vs più tabelle con meno colonne

#1 da (2 voti)
#2 da (2 voti)
#3 da (0 voti)

1

Quale sarebbe la migliore progettazione di DB per un sito web di social network. Una singola tabella con più colonne e meno righe o più tabelle con meno colonne ma più righe.

Ad esempio: L'utente può pubblicare un aggiornamento sul proprio muro o in un gruppo.

Due progetti di DB che potrei pensare sono:

1) UserPosts : id, userId, post, datetime UserGroupPost : id, groupId, userId, post, datetime

Problema di Potentail: potrebbe richiedere un join, che può (in futuro) essere una query lenta.

2) Post : id, userId, groupId, post, datetime (dove groupid sarebbe null se l'utente postasse sulla loro bacheca)

Potenziale problema: il ciclo su un set di dati di grandi dimensioni potrebbe richiedere un (lungo) tempo.

Dove posso ottenere prestazioni migliori quando i dati aumentano? C'è qualche altro (migliore) modo?

database mysql database-design

posta Siddharth Patel 23.06.2015 - 14:07

fonte

3 risposte

Leggi altre domande sui tag database mysql database-design

copyright privato da includere nel codice sorgente chiuso per la società [chiuso] Come usare git per i progetti che hanno file condivisi

score 2 · Answer 1

Ogni cosa ("Entità") che può esistere da sola, indipendentemente da qualsiasi altra cosa, dovrebbe avere una propria tabella.

Utente : id, nome, hashed_password, join_date, birth_date

Gruppo : id, nome

Le relazioni tra le cose richiedono generalmente richiedono tabelle di "collegamento".

Post : id, user_id, group_id, post_date, post_title, post_content

La chiave del successo è la indicizzazione corretta di qualsiasi campo in cui ti unisci tra le tabelle o in cui filtri i risultati.
Inoltre, considera l'utilizzo di un valore di gruppo fittizio (non NULL) per i post di un "muro" dell'utente - I valori NULL sono spesso non inclusi negli indici, che renderanno le tue query per questi post eseguiti [lontano] Più lentamente.

score 2 · Answer 2

I join non sono lenti. Sono incredibilmente veloci se ti unisci a una chiave primaria oa una colonna indicizzata. Dovresti non prendere decisioni di progettazione partendo dal presupposto che l'unione è un problema.

Ora, potrebbero esserci casi particolari, ad es. con dataset molto grandi o database distribuiti, dove l'unione può essere un problema di prestazioni, e ci sono vari modi per attenuarlo (viste indicizzate, denormalizzazione, memorizzazione nella cache), ma poiché non si dice che si hanno questi problemi specifici, direi sarebbe una prematura ottimizzazione a cui pensare.

A meno che tu non abbia problemi molto specifici, dovresti progettare i tuoi dati normalizzati, e poi usare indici ecc. per evitare problemi di prestazioni.

score 0 · Answer 3

Vorrei andare ancora oltre:

Utente: Id, Nome, WallId

Posta : Id, Contenuto, Titolo, WallId etc ...

Muro: WallId

Gruppo: Id, Nome, WallId ...

In sostanza, il post appartiene a un muro. Wall può appartenere a un utente o a un gruppo.