Diseño de tablas

[nico92_river]

Buenas gente, estoy trabajando en un nuevo sistema y me surgió una duda a la hora de diseñar la base de datos.

Supongamos que dispongo de las siguientes secciones:

Fotos
Posts
Perfil

Yo quiero que en las tres secciones se puedan dejar comentarios libremente.

Què es conveniente?? Crear tres tablas que sean

fotos_comentarios
foto_id
comentarioText

posts_comentarios
post_id
comentarioText

perfil_comentarios
perfil_id
comentarioText

O una tabla para todas las secciones que sea asi??

comentarios
tipoSeccion (foto,perfil o post)
objectId (Id de la foto, post o perfil)
comentarioText


Simplifiqué bastante el ejemplo.. pero serían varias mas las tablas ya que quiero que casi todo el sitio sea comentable y existen muchas mas secciones...

Gracias desde ya. Saludos!!

[quimfv]

Yo lo haria con 2 tablas (ademas de la de objetos claro...)

comentarios
idComentario PK
comentario
idSeccion FK
idObject FK

secciones
idSeccion
seccion

Esto aguanta tantas secciones como quieras ....

Y no vas a guardar quien a hecho el comentario... idUsuario...


Si la tabla de objetos es una sola quizas es mejor guardar el tipo en el objeto y no en los comentarios

Objetos
idObject
idSeccion
...

comentarios
idComentario PK
comentario
idObject FK

secciones
idSeccion
seccion

[gnzsoloyo]

Hay dos formas de encarar el problema:
1) Si nos atenemos a un esquema ortodoxo, debería haber una tabla de comentarios por cada una de las entidades descriptas. Esa sería la solución de manual.
2) Si la planteamos como metaentidades, requeriría sólo dos tabla: una que administre las metaentidades y la otra que contenga los datos. Es es esencialmente el modelo que usa, por ejemplo, Wordpress. Una tabla contiene el tipo de entidad representada en las tablas, su código y descripción, y la otra tiene el codigo, el dato o contenido y el link o ruta, si corresponde.
¿Cuál es la mejor solución?
Bueno, con la primera te aseguras integridad referencial, normalización de las relaciones, dependencias funcionales pulidas y mejores búsquedas... pero una programación algo más detallada.
Con la segunda te aseguras la ventaja de rapidez de diseño, y búsquedas concentradas con menos código.
¿Cuál es mejor?
Ninguna.
¿Cual es peor?
Ninguna.
Es una decisión de diseño, y está relacionada con la meta de tu proyecto.

Ahora bien, si tu web apunta a aspectos comerciales, la segunda no es una buena opción (es largo de explicar), sería preferible la primera.

[nico92_river]

Hola quim, gracias por la respuesta. El segundo método que menciono en el mensaje es básicamente así como mencionas..

Mi duda en cuanto a esto es.. en cuanto yo quiera seleccionar desde una foto (por ejemplo) los comentarios.. debería hacer algo como lo siguiente:

select * from comentarios as c
inner join secciones as s ON s.idSeccion = c.idSeccion
WHERE s.idSeccion = 'IDSECCIONFOTO' AND
c.objectId = 'id De la foto'

Esto realentizará mucho las consultas en el sitio?? Considerando que la tabla comentarios podria llegar a tener una graaan cantidad de registros...

[nico92_river]

Hola gnzsoloyo. Gracias por la respuesta!

Supongo que es la solucion que voy a terminar implementando.. simplemente me parecia un poco inadecuado crear tantas tablas.

Saludos!

[quimfv]

Con la segunda opcion no necesitas hacer el join a la tabla secciones puesto que con el id del objeto ya esta seleccionando bien los comentarios.... Si puede llegar a ser muy grande, luego tendras que definir indices que facilitan la lectura u optar por la opción de libro que te comenta gzsoloyo.

select * from comentarios as c
WHERE c.objectId = 'id De la foto'

[nico92_river]

Mmm pero puede llegar a haber un perfil con el mismo id, verdad??

es decir.. los id son autoincrementables en cada tabla.. asi que van a haber

fotos con id 1
posts con id 1
perfiles con id 1

es por eso que filtro también por sección.

[gnzsoloyo]

La tabla de perfiles si necesita ser única.
No confundas los conceptos: Un perfil, una categoría y demás cosas, no son metaentidades. Estas se usan sólo para aquellas cosas que pueden ser comunes y no son críticas, como los comentarios.