¿Qué es mejor una tabla con todos los datos o varias tablas?

[XavierC]

Hola,

tengo una duda a la hora de plantear las tablas para una aplicación, sobre todo tengo dudas en cuanto al rendimiento y la escalabilidad de las dos opciones que me planteo y me gustaría saber si alguien se ha encontrado con esta misma duda (seguro que sí) y que me puede recomendar.

Explico brevemente la aplicación:
Es una aplicación web en la que se podrán crear noticias y eventos, luego tendrá un sistema de validación de usuarios y un administrador seleccionará manualmente para cada noticia o evento que usuarios pueden verla.

Mi duda es la siguiente, la tabla de eventos y la tabla de noticias se parecen mucho y no se si debería utilizar una sola tabla de contenido y diferenciar por tipo o hacer dos tablas, una para eventos y otra para noticias.

Tablas opción 1:
noticias (Tabla que almacena las noticias)
eventos (Tabla que almacena los eventos)
usuarios (Tabla que almacena los usuarios)
usuarios_noticias (Tabla que relaciona el id del usuario y el id de la noticia)
usuarios_eventos (Tabla que relaciona el id del usuario y el id del evento)

Tablas opción 2:
contenidos (Tabla que almacena el contenido y diferencia por el campo tipo: noticias o eventos)
usuarios (Tabla que almacena los usuarios)
usuarios_contenidos (Tabla que relaciona el id del usuario y el id del evento)

La primera opción me preocupa ya que tengo que tener varias tablas para relacionar los usuarios y podría ser complicado de manejar si los datos aumentan. Si luego quiero añadir una tercera tabla de por ejemplo, "documentos", debería añadir otra tabla para relacionar usuarios_documentos.

La segunda también me genera dudas ya que al estar todo en la misma tabla esa tabla puede crecer excesivamente y afectar al rendimiento de las consultas.

Por último comentar que utilizo el framework de programación Yii de PHP y mi base de datos es Innodb, no MyISAM.

Bueno, ahí está mi duda.

Cualquier comentaría será bien recibido.

Gracias de antemano y un saludo.

[miktrv]

Depende un poco del uso que le des a estas tablas. Por ejemplo, si tienen sentido por separado, y las vas a usar por separado, es mucho mejor separarlas, también por temas de crecimiento. Si vas a usarlo siempre todo junto, es mejor que lo mantengas unido, pero depende de tu sistema.

Un saludo!

[XavierC]

Gracias miktrv,

En principio yo también pienso que tienen sentido las tablas por separado pero me surge la duda de si será muy complicado de mantener una base de datos con tantas tablas relacionales de n-n ya que para cada tabla que quiera relacionar con usuarios (todas las tablas) voy a tener que hacer una tabla relacional.

Sobre todo no se si se complicará mucho la cosa a la hora de programar la aplicación que acceda a tantas tablas distintas para hacer lo mismo...

¡Son dudas que me surgen! jeje

Gracias de nuevo por tu comentario, lo tendré muy en cuenta ;)

[davikt]

Hola XavierC,

Normalmente todo esto de privilegios se administra por grupos y te olvidas de esas n-n que son difíciles de tratar. Te propongo que sustituyas las dos tablas de usuarios_noticias y usuarios_eventos por otra con el nombre de grupos (una id auto numérica, una id_grupo y un id_user(FK)) y luego añade en noticias y eventos tantas columnas como grupos hayas creado, y las haces o boolean o byte... como veas. Eso si no te quieres comer mucho la cabeza. De esta forma te quedará una cosa así:

Noticia | Grupo1 | Grupo2 | Grupo 3
portada | 1 (tiene permisos) | 0 (no tiene permisos) | 1 (tiene permisos)

¡Un saludo!

[quimfv]

Si el numero de grupos es estable y reducido no es mala solución pero si es grande y variable te puede traer problemas puesto que poner y quitar campos de una tabla seguramente tendrá efectos sobre la programación...

[XavierC]

Hola davikt,

gracias por tu respuesta.

En principio no veo mal lo de los grupos pero me surgen algunas dudas.

Por ejemplo:

Yo tengo dos usuarios asociados a al grupo1: usuario1 y usuario2.

En la tabla de noticias tengo la columna grupo1 y para la entrada de portada he marcado que tienen permiso.

Hasta aquí lo tengo claro.

Ahora tengo una segunda noticia que se llama noticia2 pero a esta, solo quiero que acceda el usuario1 y descartar el usuario2.

¿Debería crear otro grupo solo con el usuario1 y añadir la columna?

Además, los usuarios se supone que deben ir incrementando, cuando se registren ¿A que grupo los asocio?

Creo que en este caso los grupos serán dinámicos así que me surge también la duda de si debería añadir columnas para cada grupo cada vez.

Bueno, seguiré pensando en tu planteamiento.

Gracias de nuevo, necesitaba recibir este tipo de ideas para expandir mi mente

[fahs82]

yo manejo varias tablas y a la perfeccion todo usando las primary keys a partir de el objeto principal , en mi caso son productos y en tu caso son usuarios yo diria que tengas como principal la tabla usuarios y un autoincrementable que sea el id el cual sera la llave primaria e indexada lo que te dara mayor velocidad en las consultas , las demas tablas serian tablas secundarias por asi decirlo el objeto de esta tabla estaria relacionado con el id del usuario , asi si necesitas agregar por ejemplo la tabla documentos solo la añades y mantienes las relaciones con el id del usuario sin necesidad de volcar o rehacer la tabla principal ni afectar la integridad de la base completa o las demas tablas solo es cosa de estar bien organizado , a la larga me parece esto te puede eficientar mucho el trabajo con cargas de consultas grandes sin tener que estar bloqueando o esperando comits de la tabla