Hola a todos!

Estoy desarrollando una aplicación web que consiste en una red social (tipo Tuenti, Facebook) sencilla.

Ya había entregado para un trabajo de la universidad una versión muy "cutre" y para evitar complicación con la base de datos fija. Es decir tenía una tabla para todas las fotos que se subieran, otra tabla para todos los comentarios que tuvieran todas las cuentas, otra tabla para todos los comentarios de todas las fotografías subidas... etc

Es decir, todo en plan general para no tener que crear tablas dinámicamente en la aplicación para cada usuario, etc

El esquema era algo así para que sea más facil verlo:



Bueno esto era una "chapuza" pero bueno se me pedía más detalle en la documentación del proyecto que no en el proyecto en sí.

Ahora voy a realizar el PFC sobre este trabajo, pero ampilándolo y mejorando lo que tenía.

Aparte de otras cosas que voy a introducir, como mensajes privados, álbums para tener las fotos, un blog en el tablon, etc....

La principal cosa es el diseño de la base de datos, que imagino que en una aplicación como esta que se supone va a tener grandes cantidades de usuarios, cada usuario grandes cantidades de fotos, comentarios, etc... Ese esquema es una aberración a la eficiencia para buscar los datos.

Lo que tengo en mente es que cada vez que se registra un usuario se le crean automáticamente la tabla "comentarioscuenta_idcuenta" donde "idcuenta" es el identificador de la cuenta.

Así mismo se crearía una tabla "fotoscuenta_idcuenta" para las fotos que suba esa cuenta, "albums_idcuenta" para los albums que tenga esa cuenta... etc

Esto haría que por cada usuario tengamos unas 5 o 6 tablas, pero imagino que aunque tengamos "miles de tablas" en la base de datos, la eficiencia sería enorme comparado con tener 6 tablas y millones de datos en cada una.

Si mi planteamiento es incorrecto o no está del todo bien, me gustaría que me dierais consejo con vuestra experiencia.


Otra duda que tengo, es en el ejemplo de los comentarios que tiene cada foto.

Lo lógico con este esquema, sería crear una tabla de comentarios por cada foto subida. Pero no se hasta que punto esto podría ser eficiente, ya que entonces tendríamos miles o millones de tablas, puesto que se espera tener miles o millones de fotografías subidas. Y habría fotos que no tendrían comentarios, u otras que tendrían pocos...

Entonces, ¿qué sería más eficiente? Crear una tabla para los comentarios que tengan todas las fotos subidas por un usuario (así solo habría tantas tablas como usuarios), o crear como he comentado antes, una tabla de comentarios por cada foto subida.


Un saludo y gracias por vuestro tiempo

pues la aberracion es crear 2 tablas que estan relacionadas logicamente pero no en la base de datos

fotos y comentarios fotos deberian estar relacionadas no? de 1 a muchos y ya que nos n:n no necesitas la tabla "relacionesfotos"

no hace falta crear muchas tablas para no tener muchos datos por tabla, es mejor tener muchos datos en cada tabla (asi eliminas la redundancia en tablas con distinto nombre) y sabiendo relacionarlas optimizarias tu sistema

Es una sobrecarga lógica que no tiene sentido, no me resulta complicado pensar en un escenario en que no puedas hacer claves foráneas porque no sepas a que tabla van, lo que haría que fuera poco mantenible.

Internamente el SGBBDD puede fragmentar vertical u horizontalmente las tablas para ganar eficiencia, y seguramente puedas configurarlo para indicarle cómo quieres hacerlo, si crees que sabes hacerlo mejor que él.

Deberías echarle un vistazo a cosas como ésta: http://portal.acm.org/citation.cfm?id=1454227

Pero más general, las tripletas te dan igual, lo que tienes que ver es en aplicaciones generales cómo van las BBDD.

Luego guarda las referencias, que un PFC sin referencias es una patraña. Si tienes un blog o algo así puedes luego poner un resumen en el blog, eso siempre queda bien.

Bueno, he diseñado ya más o menos la base de datos y he sacado un diagrama E-R



Aver si me podéis dar vuestra opinión de que os parece... 

He quitado la tabla que tenía anteriormente como "infocuentas" que era como una ampliación de los atributos de la cuenta, ya que de normal solo se trabajaba con unos pocos.
Pero he decidido poner todo en una misma tabla, y luego desde la aplicación ya realizaré las funciones necesarias para obtener los datos que quiera.

El tema que haya comentarios a usuarios, a fotos, o los mensajes con 0-1 usuarios es porque he pensado en que deje el valor NULL cuando un usuario es eliminado (en vez de borrar sus mensajes y comentarios) y desde la apliación tendré esto en cuenta para mostrar el nombre como "Usuario eliminado" pero que se puedan ver los mensajes.

También lo he hecho en los mensajes "privados", para que si se borra un usuario que te había enviado un mensaje, no se te borre el mensaje, aunque si que te mostrará "Usuario eliminado" y no el nombre del que te venía (Que ya no existirá).

----------------------------------------

Tengo una duda, que ya no me acuerdo como se hacía.

En la tabla "amistades" por ejemplo, tengo "idcuenta1" e "idcuenta2", son la clave primaria, pero además no puede haber otra fila con los mismos valores pero invertidos.
E imagino que al tenerlo como ahora, si que me dejaría tener por ejemplo:

Idcuenta1 Idcuenta2
1              2
2              1

¿Cómo se indica para que no puedan repetirse de este modo?

---------------------------------------

Y otra duda, ¿sería recomendable introducir dentro de la clave primaria las claves foráneas?

Por ejemplo en la tabla "Fotos"  tengo el "idfoto" solamente como clave primaria.
Aunque con eso ya basta, sería mejor añadir "idcuenta"?


Un saludo y muchas gracias