duda de estructura y diseño

[leif_sk8er]

Buenas,
Estoy desarrollando una red social y tengo una duda en cuanto a la forma en la que guardar unos registros en las tablas.

Para que os hagais una idea quiero hacer lo mismo que hace facebook en su primera pagina cuando entras con tu usuario, que te muestra todas las novedades, o como en tuenti cuando sale todo lo nuevo que ha pasado con tus amigos.

Para organizar todas las cosas que pasan he creado una tabla de esta forma llamada movimientos:

movimientos
|-- ID
|-- FECHA
|-- ID_USUARIO
|-- ID_GRUPO
|-- ID_SECCION
|-- ID_ELEMENTO
|-- ACCION
|-- SECCION_OBJETO
|-- ELEMENTO_OBJETO
|-- ACCION_OBJETO


Os explico un poco, ID_USUARIO es el ID del usuario que realiza el movimiento, ID_GRUPO es por si indica que ese movimiento lo deben saber unicamente un ID al que pertenecen solo unas personas (Evitando que se enteren todos sus contactos), ID_SECCION es el ID de la zona donde realiza una accion (Por ejemplo si pone un comentario a un usuario el ID_SECCION es 1 y el ID_ELEMNTO es el ID del otro usuario, y la accion es 1 que es la de comentario), SECCION_OBJETO, SECCION_ELEMENTO y ACCION_OBJETO es para cuando es necesario guardar un ID de alguna cosa que hace relacion al movimiento, por ejemplo el ID del comentario o cosas similares

El problema es que una vez filtre los movimientos que le atañan a un usuario para cada una de esas filas devueltas deberé hacer una nueva consulta o dos para sacar los nombres de las cosas. Es decir que como dependiendo de cada accion las cosas que tiene que hacer son muy diferentes parece que es la unica forma.

Mi duda es: ¿Seria mejor guardar en esa tabla los movimientos de todos? o es mejor para cada usuario crear una tabla de movimientos unica solo con sus movimientos?


Por otro lado, y para evitar hacer todas esas consultas cada vez, se me habia ocurrido crear un xml con una estructura similar a la tabla pero ya con los nombres y todo puesto para luego solo parsearlo. El problema es que si yo hago un movimiento que hay 100 amigos que deben enterarse tendré que actualizar 1000 ficheros de golpe, haciendo que tarde mucho, mientras que de la forma de las consultas a cada usuario le tardará un poco solo.


No se, estoy bastante perdido y liado en este asunto por que alucino lo rapido que lo hace facebook con tantas cosas diferentes que tiene, y cuando yo tenga en una tabla 100,000 o 1,000,000 de registros va a ser eso eternamente lento.


A ver si podéis ayudarme, o si se os ocurre una buena forma de guardar los registros o filtrarlos toda ayuda es agradecida. Si no entendieseis alguna cosa decirmelo que os lo intento explicar mas a ver si consigo solucionar este aspecto que en casi todos los proyectos va a salirme como duda.

[gnzsoloyo]

El problema es que una vez filtre los movimientos que le atañan a un usuario para cada una de esas filas devueltas deberé hacer una nueva consulta o dos para sacar los nombres de las cosas. Es decir que como dependiendo de cada accion las cosas que tiene que hacer son muy diferentes parece que es la unica forma.

Mi duda es: ¿Seria mejor guardar en esa tabla los movimientos de todos? o es mejor para cada usuario crear una tabla de movimientos unica solo con sus movimientos?

Hay muchas cosas a considerar si lo que realmente quieres hacer es una social network, pero por principio, si lo que vas a diseñar es el sistema que lo gestiona, no te tienes que perder de entrada en las minucias. Te estás planteando cómo lograr programar los procesos, cuando todavía no sabes qué procesos tienes que hacer...
Trata de alejarte un poco, toma una pizarra o lo que quieras, y bosqueja en un diagrama lo que esa SN tiene que mostrar y qué es lo que los usuarios deben poder hacer. Los procesos vienen después y el diseño de la base de datos viene después incluso de los procesos.
No puedes diseñar una base sin saber qué tipo de información (contenida en los procesos de los usuarios) va a contener, simplemente porque aún no has determinado que entidades participan del modelo.

Incluso, si lo que quieres es un esquema previo de cómo trabajan, para poder inspirarte y que te sirva de guía, en en cuenta que el esquema general de una SN ya está creado, no es necesario que inventes nada, simplemente que te documentes.

Un modelado general de una SN sería:



Este tipo de modelo es el que usan Bebo, BlackPlanet, FaceBook, Friendster, Google's OpenSocial, Orkut, iGoogle, LinkedIn, Live Spaces, MySpace, Slide, Twitter, TwitterVision y otros.

Documentación sobre el tema la puedes encontrar en Library of Free Data Models

Por otro lado, y para evitar hacer todas esas consultas cada vez, se me habia ocurrido crear un xml con una estructura similar a la tabla pero ya con los nombres y todo puesto para luego solo parsearlo. El problema es que si yo hago un movimiento que hay 100 amigos que deben enterarse tendré que actualizar 1000 ficheros de golpe, haciendo que tarde mucho, mientras que de la forma de las consultas a cada usuario le tardará un poco solo.

No se, estoy bastante perdido y liado en este asunto por que alucino lo rapido que lo hace facebook con tantas cosas diferentes que tiene, y cuando yo tenga en una tabla 100,000 o 1,000,000 de registros va a ser eso eternamente lento.

Un consejo que si puedo darte es que no tienes que ponerte a pensar como "ahorrar" codificación, desarrollo, consultas, procesos. No hay en este tipo de proyectos cosas que pudeas "ahorrarte", son demasiado grandes y complejos como para plantearte atajos. Es mejor ser más ortodoxo, hacer las cosas de manual y no encontrarte que luego lo que tienes es insuficiente y tener que empezar a parchar lo que ya está siendo usado...

Buena suerte con el proyecto...

[leif_sk8er]

Muchas gracias gnzsoloyo, no sabia que existiesen estos esquemas ya realizados, ni mucho menos que todos estos portales siguiesen una misma estructura inicial.

Alomejor no me expliqué correctamente, todo este primer paso de pensar el diseño en papel y luego preparar las tablas ya lo tengo listo. El problema era que no sabia si lo estaba haciendo bien.

Ten en cuenta que por las diferentes secciones y condiciones si solo queremos mostrar 50 movimientos las 100 o 120 consultas, y imaginate que lo hacen 10 personas a la vez, no parece un sistema muy optimizado, deberia intentar que saliese todo en como mucho 5 consultas...

No se, no me acaba.

Mi modelo de movimientos no es muy diferente a ese que pusistes, solo que tiene mas campos dependiendo el tipo de movimiento y el tipo de accion que realiza.

La red social la tengo casi terminada pero solo me falta el tema de los movimientos, para poder crear los muros del usuario.

Imaginate esto: Un usuario le gusta una cancion de otro usuario, pues entonces seria algo asi
|-- ID = auto
|-- FECHA = time()
|-- ID_USUARIO = el id del usuario que hace el movimiento, el que pulsa en me gusta
|-- ID_GRUPO = 0, por que quiere que todos sus amigos se enteren del movimiento
|-- ID_SECCION = 1, se está haciendo un moviminto relacionado a otro usuario
|-- ID_ELEMENTO = X, es el ID del otro usuario
|-- ACCION = 0, no se le aplica una accion al usuario directamente, si no a algo que posee el usuario dentro (en este caso una cancion)
|-- SECCION_OBJETO = 5, le gusta una cancion
|-- ELEMENTO_OBJETO = X, ID de la cancion
|-- ACCION_OBJETO = 1, es el valor que se le aplica cuando se refiere a gustar.


Eso quiere decir que si quieres sacar luego el nombre del usuario, y el nombre de la cancion son dos consultas mas, y claro no se puede hacer en subconsultas al principio para ponerla dentro de una sola consulta por que dependiendo el ID de la seccion tiene que cojer luego una tabla o otra para relacionarlo con la de canciones o con la de peliculas... ect ect.

A ver si podéis echarme una mano para reducir tantas consultas o poner un sistema o solucion totalmente diferente.