2012-01-26 21 views
11

Realizzo un sito Web in cui sono presenti diversi tipi di elementi come blog, post, articoli e così via. Un utente può impostare uno di loro come il suo preferito. Ora, quando mi avvicino questa cosa, ho due opzioniProgettazione database: più tabelle rispetto a una tabella singola

  1. fare un tavolo per favoriti utente per ogni tipo di oggetto.
  2. Creare una tabella comune per tutti i tipi di oggetti per tutti gli utenti.

Il problema con il 1 ° struttura è che dovrò interrogare un sacco di tavoli per la visualizzazione dei preferiti di un particolare utente. Ma mi consentirà di raggruppare facilmente i preferiti in diverse categorie.

Tuttavia, se devo mostrare tutti i preferiti su una singola pagina e unirli tutti, ordinati in base al tempo, diventa difficile. Ma se uso il secondo modello, posso facilmente ottenere gli ultimi preferiti, e anche il raggrupparli in base al tipo di oggetto non è difficile, ma avrò un ampio sito di tabelle.

Quale delle due strategie sarà più scalabile.

Il primo comprende più query di database e il secondo comprende una grande tabella singola.

Se aiuta, sto usando MySql

+0

# 2, se la tabella è indicizzata correttamente, il rendimento della query rispetto a quella tabella di grandi dimensioni dovrebbe essere simile a # 1. –

risposta

8

Sembra che tu già conosca la risposta, ma ricorda, tieni i sistemi che progetti facilmente da modificare in quanto i modelli di business cambiano sempre nel tempo o alla fine falliscono (è una generalizzazione ma ottieni l'idea). Un corollario di ciò è che se si realizza un modello rigido, veloce o lento, è rigido, i cambiamenti saranno più difficili e l'utente finale non vedrà la differenza, quindi non si ottiene alcun cambiamento di denaro/felicità, a meno che non si tratti di un brutto cambiamento. Il tuo problema non è tecnico in un modo in cui una query funziona sul motore ma più filosofica, facili cambiamenti rispetto alla velocità apparente. Chiediti, qual è il vantaggio di avere un database normalizzato? Pensa a un'architettura e un design puliti, le prestazioni sono il problema minore nel mondo di oggi dato che l'elaborazione è più economica e anche l'archiviazione. Ma il design è costoso. La normalizzazione è stata fatta per rendere i sistemi che non dipendono dalle decisioni dell'ultimo momento, ma da un processo di progettazione strutturata. I grandi tavoli non sono un grosso problema per MySql ma sono un grosso problema da mantenere, modificare ed espandere. Non si tratta solo di aggiungere una colonna in più, si tratta della struttura rigida dei dati stessi. Alla fine, nel tempo, aggiungerai solo colonne che contengono indici e quegli indici punteranno a tabelle piccole. MySql adotterà comunque tutti i dati. Quindi andrò per il primo, un sacco di tavolini, molti a molti.

4

ho questo disegno sul mio sito web. I miei moduli sono: notizie, articoli, video, foto, download, recensioni, quiz, sondaggi, ecc. Tutto in tabelle separate. Ho una tabella simile a cui gli utenti possono piacere o non gradire un post (nel tuo caso preferiti). La query per ottenere questi non è così complicato.

Prima di tutto per la maggior parte maggior parte dei miei tavoli per i moduli sono strutturati allo stesso modo:

  • id
  • titolo
  • contenuti
  • user_id (autore)
  • data
  • ecc

con alcune eccezioni che a volte il titolo è chiamato domanda o non c'è una colonna di contenuto. Ciò non causa problemi.

miei gusti tavoli è impostato in questo modo:

  • id
  • page_id
  • module_id (che tabella si è arrivati ​​da ...Ho una tabella moduli in cui ogni modulo ha un titolo, associato id, directory, ecc)
  • post_id (corrisponde alla tabella di modulo ID)
  • id_utente (utente che ha fatto la simpatia o invio)
  • stato (0 = come, 1 = non amano)
  • data (quando la simpatia/antipatia ha avuto luogo)

tavolo Moduli esempio:

  • id
  • titolo
  • directory
  • post_type

Esempio

id  title    directory   post_type 
1  News    news    news 
2  Episode Guide  episodes   episode 
3  Albums   discography/albums album 

Essenzialmente vostro avrebbe un set up simile, modificando la struttura della tabella, se necessario, per le vostre esigenze.

query per ottenere tutti i simili o preferiti per un particolare utente:

$getlikes = mysql_query("SELECT DISTINCT post_id, module_id, page_id FROM likes WHERE user_id = $profile_id ORDER BY id DESC LIMIT $offset, $likes_limit", $conn); 
$likes = mysql_num_rows($getlikes); 

if($likes == "0"){ 
echo "<br><Center>$profile_username does not have any liked posts at this time.</center><BR>"; 
} 
else { 
echo "<table width='100%' cellspacing='0' cellpadding='5'> 

<Tr><th>Post</th><th align='center'>Module</th><th align='center'>Page</th><tr>"; 

while ($rowlikes = mysql_fetch_assoc($getlikes)) { 
    // echo data 

$like_page_id = $rowlikes['page_id']; 
$like_module_id = $rowlikes['module_id']; 
$like_post_id = $rowlikes['post_id']; 


// different modules have different fields for the "title", most are called title but quotes is called "content" and polls is called "questions" 
if($like_module_id == "11"){ 
$field = "question"; 
} 
elseif($like_module_id == "19"){ 
$field = "content"; 
} 
else{ 
$field = "title"; 
} 





// FUNCTIONS 
PostURL($like_page_id, $like_module_id, $like_post_id); 
ModTitle($like_module_id); 
ModTable($like_module_id); 
ModURL($like_page_id, $like_module_id); 
fpgURL($like_page_id); 


$getpostinfo = mysql_query("SELECT $field AS field FROM $mod_table WHERE id = $like_post_id", $conn); 
$rowpostinfo = mysql_fetch_assoc($getpostinfo); 
$like_post_title = $rowpostinfo['field']; 

// Using my "tiny" function to shorten the title if the module is "Quotes" 
if($like_module_id == "19"){ 
Tiny($like_post_title, "75"); 
$like_post_title = "\"$tiny\""; 
} 


if(!$like_post_title){ 
$like_post_title = "<i>Unknown</i>"; 
} 
else { 
$like_post_title = "<a href='$post_url'>$like_post_title</a>"; 
} 

echo "<tr class='$altrow'> 
<td>$like_post_title</td> 
<td align='center'><a href='$mod_url'>$mod_title</a></td> 
<td align='center'>$fpg_url</td> 


</tr>"; 

$altrow = ($altrow == 'altrow')?'':'altrow'; 

} // end while 

echo "<tr><Td align='center' colspan='3'>"; 

// FUNCTIONS - Pagination links 
PaginationLinks("$cs_url/users/$profile_id", "likes"); 

echo "</td></tr></table>"; 

} // end else if no likes 

Ok che potrebbe essere difficile per voi di capire dal momento che ho un sacco di mie variabili, ma in fondo si ottiene il modulo ID e post id dalla tabella dei like e quindi esegue una query per ottenere il titolo del post e qualsiasi altra informazione che desidero come l'autore originale.

Ho impostato le funzioni "modulo" che restituiranno l'url o il titolo del modulo dato che fornisci un ID per esso.

+0

Hey, grazie mille per la risposta esaustiva che hai dato. Ho anche una struttura abbastanza simile alla tua, quindi non è difficile tenerla nello stesso tavolo. Inoltre sto lavorando a 'Django' framework di python che ha una chiave straniera generica. Questo mi consente di mantenere riferimenti a oggetti diversi nella stessa tabella. Ma la mia domanda non operativa è più basata sulle prestazioni. Cosa accadrebbe quando il numero di utenti aumentasse e queste tabelle iniziassero a riempirsi? – Sachin

Problemi correlati