Tabella singola con più colonne vs più tabelle con meno colonne

8

Quale sarebbe una migliore progettazione di database 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: un utente può pubblicare un aggiornamento sulla propria bacheca o in un gruppo.

Due progetti di database a cui riesco a pensare sono:

Design 1

UserPosts

id
ID utente
inviare
appuntamento

UserGroupPost :

id
groupId
ID utente
inviare
appuntamento

Potenziale problema : potrebbe richiedere un join, che può (in futuro) essere una query lenta.

Design 2

Messaggi :

id
ID utente
groupId
inviare
datetime (dove groupid sarebbe nullo se l'utente post sulla propria bacheca)

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

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

mysql database-design

— Siddharth Patel
fonte

Per me, poche colonne più righe. È facile gestire una porzione per porzione piuttosto che avere un set di dati di grandi dimensioni. Se la tua grande preoccupazione sono i grandi dati in futuro, non farlo. Il server SQL è progettato con questo tipo di problema, tutto ciò che devi fare è progettarlo correttamente. Avere un set di dati di grandi dimensioni non è un problema se sai come ottimizzare la tua query

— Vincent Dagpin,

L'uso del piano di esecuzione è davvero di grande aiuto. Ti dice qual è il problema con la tua query. Ps: non fare il ciclo, se possibile usa l'elaborazione in

— blocco

2

La mia inclinazione qui sarebbe sempre l'opzione di progettazione 1, o almeno lungo quelle linee. Non preoccuparti troppo di provare a eliminare la necessità di unire le tabelle nelle query future: qualsiasi database normalizzato utilizzerà i join in qualsiasi query utile, ovvero solo database relazionali.

Inoltre, perché dovresti necessariamente unirti alle tabelle userPosts e userGroupPosts per il tuo sito web? Non sarebbero visualizzati separatamente? L'unico motivo per cui dovresti unirti a queste tabelle è forse quando cerchi post, ma non dovrebbe essere troppo difficile scrivere query efficaci per questo. A parte questo, potresti voler interrogare le tabelle a scopo di analisi, ma questo non è lo scopo principale di questo database.

Design 2 potrebbe almeno significare che si finisce con un tavolo molto impegnato.

L'opzione migliore sarebbe quella di prototipare ciascuno ed eseguire alcuni test. Costruisci un prototipo di ciascuna opzione di progettazione ed esegui alcuni benchmarking delle prestazioni su diverse operazioni con alcuni dati fittizi.

— Ian_H
fonte

-3

Per me, secondo la tua attuale struttura, Design 2 è meglio. È possibile implementare il partizionamento, la query ottimizzata e il modo strutturato per creare database / tabelle ridurrà i tempi di esecuzione. Ma la normalizzazione di alcuni casi funziona meglio, ma dipende totalmente dall'architettura di progettazione del database.

— Dipa
fonte