MySQL: Application Table Design

Question

MySQL: Application Table Design

#1 da (0 voti)

0

Sto creando un nuovo sito che avrà molti oggetti, come post (testo / foto / video), prodotti, gallerie fotografiche, ecc.

Attualmente il mio progetto consiste nel mettere tutti gli oggetti in una tabella posts , ma comincio a chiedermi se potrebbe essere troppo restrittivo.

Ho anche una tabella pivot post_tag ...

Sarebbe meglio creare una tabella posts e una tabella products e una tabella videos , ecc.? So che la tabella posts potrebbe diventare grande, ma penso che sarebbe anche più facile da mantenere. OTOH Potrei rompere ogni tabella di oggetti in un database separato se mai se ne presentasse la necessità, il che (penso?) Aiuterebbe con la scalabilità, il che significherebbe anche che probabilmente avrei bisogno di più tabelle pivot: tag_video , product_tag , ecc .per ogni tabella di oggetti?

Sono curioso: come fa Tumblr a fare questo per ognuno dei loro tipi di post ...?

Qualche idea sarebbe molto apprezzata!

mysql application-design

posta timgavin 05.11.2015 - 02:01

fonte

1 risposta

Leggi altre domande sui tag mysql application-design

Che cosa sto e io rappresentiamo in python? [duplicare] Esiste un valore che mette gli output di test / build sotto il controllo del codice sorgente?

score 0 · Accepted Answer

In definitiva ciò dipende da: Che cosa vuoi fare con il contenuto?

Una singola tabella di post funziona bene fino a quando si desidera accedere al contenuto come post . Tuttavia, diventerà piuttosto limitante se si desidera utilizzare il contenuto in modi diversi. Cosa succede se vuoi trovare tutte le immagini che sono incorporate nei post? Questo sarebbe molto difficile se hai solo una tabella dei post, dato che dovresti elaborare ogni post per trovare le immagini.

A mio parere, separare i diversi tipi di contenuto in tabelle diverse è una buona idea, perché con un sito complesso come quello che descrivi, sei quasi certo di volere funzionalità che elaboreranno il contenuto in modi diversi. Questo potrebbe non essere chiaro ora, ma è probabile che questi casi di utilizzo si presentino più tardi.

Ricorda che un numero elevato di tabelle è solo un tipo di complessità . Scrivere un sacco di codice in più per aggirare un design di database troppo semplicistico aggiunge complessità a se stante. In realtà, avere un sacco di tavoli non è un grosso problema da gestire (anche se potrebbe sembrare così all'inizio se non si ha esperienza nella progettazione del database).