2012-01-26 23 views
11

Estoy creando un sitio web donde hay diferentes tipos de elementos, como blogs, publicaciones, artículos, etc. Un usuario puede configurar cualquiera de ellos como su favorito. Ahora, cuando me acerco a esta cosa, tengo dos opcionesDiseño de base de datos: varias tablas frente a una sola tabla

  1. hacer una tabla de favoritos del usuario para cada tipo de objeto.
  2. Haz una tabla común para todo tipo de objetos para todos los usuarios.

El problema con la primera estructura es que voy a tener que consultar una gran cantidad de tablas para mostrar los favoritos de un usuario en particular. Pero me permitirá agrupar fácilmente los favoritos en diferentes categorías.

Sin embargo, si tengo que mostrar todos los favoritos en una sola página y fusionarlos todos, ordenados según el tiempo, entonces eso se vuelve difícil. Pero si utilizo el segundo modelo, puedo obtener fácilmente los últimos favoritos, y también la agrupación de acuerdo con el tipo de objeto no es difícil, pero tendré una gran tabla en el sitio.

Cuál de las dos estrategias será más escalable.

La primera implica múltiples consultas de bases de datos, y la segunda implica una gran tabla única.

Si ayuda, estoy usando MySql

+0

# 2, si la tabla es indexada correctamente, el rendimiento de la consulta con respecto a esa gran tabla debería ser similar a # 1. –

Respuesta

8

Parece que ya conoce la respuesta, pero recuerde, mantenga los sistemas que diseña fáciles de modificar ya que los modelos comerciales siempre cambian con el tiempo o fallan (es una generalización, pero se entiende la idea). Un corolario de eso es que si haces un modelo rígido, rápido o lento, es rígido, los cambios serán más difíciles y el usuario final no verá la diferencia, por lo tanto, no se logrará un cambio de dinero/felicidad, a menos que sea un cambio muy malo. Su problema no es técnico de una manera en que una consulta funciona en el motor, sino que es más filosófica, cambios fáciles en comparación con la velocidad aparente. Pregúntate, ¿cuál es la ventaja de tener una base de datos normalizada? Piense en una arquitectura y un diseño limpios, el rendimiento es el menor problema en el mundo de hoy ya que el procesamiento es más económico y el almacenamiento también. Pero el diseño es costoso. La normalización se hizo para crear sistemas que no dependen de decisiones de último momento sino de un proceso de diseño estructurado. Las tablas grandes no son un gran problema para MySql, pero son un gran negocio para mantener, modificar y expandir. No se trata solo de agregar una columna más, se trata de la estructura rígida de los datos en sí. Finalmente, con el tiempo, solo agregará columnas que contengan índices, y esos índices apuntarán a tablas pequeñas. MySql estará trabajando en todos los datos de todos modos. Así que iré por la primera, muchas mesas pequeñas, muchas a muchas.

4

tengo este diseño en mi sitio web. Mis módulos son: noticias, artículos, videos, fotos, descargas, reseñas, concursos, encuestas, etc. Todo en tablas separadas. Tengo una tabla de Me gusta en la que a los usuarios les puede gustar o desagradar una publicación (en su caso, favoritos). La consulta para obtener estos no es tan complicada.

primer lugar en su mayor parte la mayoría de mis tablas para los módulos están estructuradas de la misma manera:

  • Identificación
  • título
  • contenido
  • user_id (autor)
  • fecha
  • etc

con algunas excepciones que a veces el título se llama pregunta o no hay columna de contenido. Eso no causa ningún problema.

Mis gustos mesas está configurado de esta manera:

  • Identificación
  • page_id
  • module_id (lo que la mesa ¿Vino de ...Tengo una tabla módulos, donde cada módulo tiene un título, ID asociado, directorio, etc.)
  • post_id (corresponde al ID de tabla de módulos)
  • user_id (usuario que hizo la afición o publicación)
  • estado (0 = igual, 1 = no les gusta)
  • fecha (cuando el agrado/desagrado tuvo lugar)

Módulos ejemplo de tabla:

  • Identificación
  • título
  • directorio
  • post_type

Ejemplo

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

Esencialmente suyo tendría un conjunto similar hacia arriba, la modificación de la estructura de la tabla según sea necesario para sus necesidades.

consulta para obtener todos los gustos o favoritos para un usuario concreto:

$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 que puede ser difícil para que usted pueda entender ya que tengo un montón de mis propias variables, pero básicamente se obtiene el ID del módulo y ID de la tabla Me gusta y luego ejecuta una consulta para obtener el título de la publicación y cualquier otra información que desee como el autor original.

Tengo configuradas las funciones del "módulo" que devolverán la url o el título del módulo dado que usted proporciona una identificación para ello.

+0

Muchas gracias por la respuesta exhaustiva que me han dado. También tengo una estructura bastante similar a la tuya, por lo que mantenerla en la misma mesa no es tan difícil. Además, estoy trabajando en el framework 'pyjango' de python que tiene una clave externa genérica. Esto me permite mantener diferentes referencias de objeto en la misma tabla. Pero mi pregunta no operacional está más basada en el rendimiento. ¿Qué pasaría cuando la cantidad de usuarios aumentara y estas tablas comenzaran a llenarse? – Sachin

Cuestiones relacionadas