Diseno de aplicacion VS performance

[u_goldman]

Escenario:

Tengo un modulo de acceso especial a contenidos dentro de un sitio.
En este modulo se pueden dar de alta usuarios y grupos, los usuarios son asignados a los grupos, y los grupos a su vez son asignados a los contenidos, estos contenidos pueden ser:

Paginas
FAQ
Eventos
Noticias

Cada uno tiene una o mas tablas para su registro.

Los grupos no pueden ser eliminados si contienen usuarios, por lo tanto, para borrar estos grupos es necesario des-asignar a los usuarios de los grupos, borrando asi su relacion en la tabla de referencia usuarios-grupos.

Ok, hasta ahi todo bien, lo que me esta haciendo un poco de ruido es lo siguiente:

Cada vez que se haga una peticion a cualquiera de estos contenidos, la aplicacion hara una consulta cruzada a la tabla de referencia contenido-grupo, para determinar si el registro de cualquiera de estos contenidos pertenece a la seccion privada del sitio, si encuentra registros en la tabla cruzada, entonces hara una validacion contra cierta(s) variable de sesion para determinar si el usuario tiene acceso.


Problematica:
Lo que se me metio en la cabeza es que a lo mejor no es necesario unir la tabla de referencia cada vez, aumentando con esto el performance de la aplicacion.

Posible Solucion:
La forma en que pense que lo podria lograr es agregar un campo booleano en cada una de las tablas de contenidos, si cuando se agregan/editan estos contenidos existen grupos, el valor sera verdadero, en tanto que si no se agregan grupos, el valor sera falso, determinando con esto un estatus publico/privado.

Implicaciones:
Un grupo puede ser asignado a muchos contenidos
Un contenido puede ser parte de muchos de grupos
En el evento de eliminar un grupo, se eliminara a su vez la relacion de contenido-grupo, pero tendria que crear otro procedimiento para determinar si ese contenido, esta asignado a mas grupos para cambiar el valor de aquel campo booleano, ya que si no esta asignado a mas grupos, entonces el contenido es publico.

Para esto la alternativa seria crear un trigger, ON AFTER DELETE, que compruebe si existen mas registros, si si, entonces no altera el valor del campo, si no, entonces lo altera, convirtiendolo en contenido publico.

A todo esto, a mi forma de ver, es una rutina que podria causar problemas, quizas no sea tan facil controlar esto y no es realmente algo bien disenado, lo que necesito es que me den sus puntos de vista, valdria la pena hacer un diseno un tanto deficiente como el planteado por aumentar el performance, o en todo caso, me dejo de alucinar y hago el JOIN de estas tablas siempre?
Cabe destacar que es un sitio con alto trafico y puede tener una cantidad infinita de contenidos.

Gracias por sus recomendaciones y el tiempo que se tomaron para leer este extenso post.

Salu2,

[u_goldman]

Gracias comunidad, al final me decante por hacer el JOIN siempre, se les agradecen sus aportaciones(por que no habra un idioticon de sarcasmo)

Salu2,

[El_Metallick]

U_G te ayudaria si entendiera jajajajajaj.... aun me falta para llegar a eso en una de esas revivo el tema en 1 año mas cuando lo entienda :P jajajajaj saludos

[orharo2003]

Iniciado por u_goldman

Gracias comunidad, al final me decante por hacer el JOIN siempre, se les agradecen sus aportaciones(por que no habra un idioticon de sarcasmo)

Salu2,

pero noestás enojado ....

[u_goldman]

Iniciado por orharo2003

pero noestás enojado ....

Esto me recuerda a alguno de nuestros posts...repito, por que no habra un idioticon de sarcasmo?

[Myakire]

Pues tu colocalo igual:

Gracias comunidad, al final me decante por hacer el JOIN siempre, [SARCASMO]se les agradecen sus aportaciones[/SARCASMO]

Creo que es claro, jejeje, por cierto.....tu mensaje ni lo ví, pero si lo hubiera hecho ...... me hubiera dado flojeras leer tantas lineas, jejeje

[Neuron_376]

Por mi parte, no lo habia leido hasta ahorita... ok, si entendi mas o menos todo lo que escribiste, lo que pasa es que tienes que andar borrando de otras tablas segun privado/etc.

Bueno, Te dire lo que yo haria si es que entendi bien lo que pusiste..

1. De primero consultar y luego verificar session, cambialo por, primero consultar session luego consultar basado en el permiso que tienes.

2. Lo del campo para decir publico, privado me parece bien, pero seria un campo tipo tinyint, o char "1", me parece mejor que un booleano, y pones un index sobre ese campo jejejeje (ya sabras porque, porque puedes consultar basado en ese campo desde el principio y sacar registros adecuados segun el nivel de acceso, por eso primero verificar session, luego consultar)

3. De la parte de borrar, creo que seria mejor un estatus que pone activo/inactivo, esto siempre es mejor porque mantiene intacto el ID principal, haciendo mejor las consultas, porque ese DI principal esta intacto y es totalmente consecutivo.

4. Ahora, necesitas un JOIN para conocer las dependencias de una tabla y otra... los JOIN son mucho mejor que subconsultas, pero pues no deja de ser algo pesado, entonces, ligar tablas pesadas, da como resultados consultas pesadas, (pero ni modo, cuando se ocupa algo se hace y listo), pero para lo que necesitas, y como mencionas que es mucha info en todos lados, lo que te comviene mas es crear tablas independientes relacionadas con tablas tipo mapa , que contengan la relacion de las tablas, asi el JOIN se hace sobre tablas muy pequeñas y como todo es tipo int, es decir datos de longitud estatica, la consulta es mucho, mucho mas rapida.

Bueno, no se si algunas cosas las puedas aplicar, ni siquiera se si te entendí bien , pero eso es lo que haría yo.

Suerte!!