Foro de elhacker.net

Como hago una relacion para definir uno o muchos moderadores para un determinado foro sin llegar a una redundancia de datos.


Gracias.

pues si la relacion es de muchos a muchos (varios mods, varios foros), creas una nueva tabla con las relaciones uno a muchos y muchos a uno

moderadores >---< foros
moderadores |---<Permisos>---| foros
y moderadores es 1 a 1 o 0 con usuarios :P

Justamente lo que quiero evitar es crear un circulo entre esas 4 tablas ...

imposible, pero no te preocupes xD por cada transacción cuando mucho 3 tablas excepto cuando el moderador entra en acción... y viendo tu diagrama... cada foro puede tener 1 solo moderador? :/ por eso agregué una tabla al circulo xD permisos de mod jeje asi 1 mod puede estar en 2 foros, y 1 foro puede tener 2 mods :P

de hecho yo ampliaria el círculo aún mas xD

(http://i.elhacker.net/i?i=f9-q5iAKO5sQpU_xNJTt4mVo) (http://i.elhacker.net/d?i=f9-q5iAKO5sQpU_xNJTt4mVo)

no le hagas caso al nombre de las relaciones xD es un modelo conceptual jeje

Gracias por la respuesta haber como va esto:

1) No entiendo porque foro esta relacionado con permiso, cual es la utlidad de permiso ¡?

2) En el segundo diagrama que expuse habia hay un detalle que corta la relacion de muchos a muchos entre usuario y foro, de esa forma se entiende que un foro puede tener mas de un moderador asi como tambien un usuarios puede ser moderador de mas de un foro.

3) Las tablas hilo y respuesta se pueden unir en una sola como en mi diagrama, sigo pensando en que el ciclo que se cierra en usuarios - moderador - foro es equivoca y que generara redundancia de datos.

4) En el caso que permiso represente el grupo al que pertenece un usuario entonces ya no seria necesaria la tabla grupo.

Espero opiniones.
Saludos.

bueno... por que crees que genera redundancia de datos? mientra la accion no sea moderar tienes solo 3 tablas involucradas, y al moderar necesitas estrictamente utilizar las 4

ahora lo que no entiendo es la relacion de hilo a hilo xD

Pues claro, la relacion de hilo a hilo (recursividad) indica que un hilo (llamese post inicial), puede tener 0, 1 o muchos hilos (llamense respuestas), lo tomo asi puesto que un post inicial tiene los mismos campos que una respuesta, se identifica cuando es un Post inicial cuando el campo idhilo_res esta vacio.

Con lo de la redundancia de datos, probare con consultas y te estare informando de los resultados.

Saludos y gracias.
Tio verde. ¡¡¡

 :rolleyes: :rolleyes:

jeje... ahi si hay redundancia... entiendes por qué necesitas una tabla de "respuestas"?

de hecho, la tabla de hilos no necesariamente debe tener la publicación inicial (en la mayoría de foros es la "respuesta 0"), puede contener un id, id de usuario autor, status, cant de respuestas y otra información... título talvez :P pero por lo general se toma de la "respuesta 0", si las pones todas en "hilo" tendras redundancia en id de hilo, a menos que el la pk sea "id respuesta"

sobre lo de "permisos" hasta ahora entiendo como lo habías puesto xD es que a veces carga la imagen que puse, y otras veces las tuyas pero nunca juntas y por eso no me enteraba que habias puesto un diagrama...

si crees que ese "circulo" es un error de diseño, te invito a que veas el diagrama de una bd de smf (que tambien usa el diseño que menciono smf_topics, smf_messages)

http://img71.imageshack.us/img71/4879/databasesmfvj5.png

No puede haber redundancia en la recursividad de mi diagrama, lo he analizado bien y no creo que sea un error, el error vendria si se decide hacer como en el diagrama que adjuntas y dire porque:

Si se crean 2 tablas:

- Hilo
- Repuesta

La tabla usuario tendria que estar relacionado con ambas, esto traeria consigo redundancia, en cambio si solo se crea una tabla llamada hilo no... no se si solo sea un tabu pero siempre crei que hay que evitar esos circulos que se cierran (se que a veces es imposible pero en ocasiones si se puede).

Que opinas ¡ ?

la tabla usuario estaría relacionado con ambas pero de disitnta forma, una como creador del tema, y otro como creador de la respuesta, que no necesariamente es el mismo usuario, sobre la redundancia, si tienes idhilo como pk e idhilo_res como fk de la misma tabla... que tendrias en idhilo cuando es una respuesta?

se crea el tema:
idhilo: 10230 (pk)
idhilo_res: vacio (fk)

hasta ahí bien... pero... con una respuesta



tienes 2 registros con la misma pk, algo inadmisible xD



y así....

suponiendo que idhilo_res sea el id del hilo al que se responde, entonces la primera respuesta sería:



segunda respuesta:



supongo que determinarías el orden de las respuestas por fecha... y ahora te pregunto, que ves en este link (el de tu respuesta)
https://foro.elhacker.net/bases_de_datos/diagrama_de_bd_como_definir_moderador_para_cada_foro-t275101.0.html;msg1350330#msg1350330

ahora.. como identificas cada respuesta si no hay id_mensaje o similar...

Para un nuevo hilo seria:

- idhilo: 10230 (este es el codigo que se genera para un hilo ya sea inicial o respuesta)
- idhilo_res: vacio (significa que este es un hilo inicial y no una respuesta a uno)

Para una respuesta:

- idhilo: 10231 (este es el codigo que se genera para un hilo ya sea inicial o respuesta)
- idhilo_res: 10230 (significa que este es una respuesta y es la respuesta al hilo10230)

Es correcto ¡?

entonces para desplegar datos haces esto?

select * from hilo where idhilo = 'algo' union select * from hilo where idhilo_res = 'algo'

no me parece muy ortodoxo, al igual que la relación a la misma tabla, pero si te funciona xD...

Bueno la idea de hablar sobre redundancia era tratar de optimizar las consultas, si la relacion que propones mejora la optimizacion al hacer las consultas pues la usare.

ehm... sobre optimizacion de consultas... no necesariamente la mas corta es la mas rápida, tendrias que probar con el la base de datos fisica.. pero de eso sabe mas la tía verde xD

Eres un puñetero ...

 :rolleyes: :rolleyes: :rolleyes:

EDito : No recuerdo haber puesto puñetero.  :¬¬ :¬¬

Me he ausentado... mucho trabajo y poco tiempo.  :P

Yo tampoco le veo mucha concordancia a incluir id_hilo y id_res juntos... por una parte porque en algun punto tendras que hacer una relacion o consulta a la misma tabla como el ejemplo que te expuso Napk y si analizamos el ejemplo expuesto por Napk, aca en esa simple consulta el motor tendra la optimizacion suficiente para buscar datos cuando se encuentre con esto:

select * from hilo where idhilo = 'algo'

y cuando se encuentre con esto otro:

select * from hilo where idhilo_res = 'algo'

Porque son consultas haciendo referencia a una pk constante pero... cuando le incluyes el UNION ahi el motor para dicho predicado no filtra nada... hara una busquedad de todos los registros que poseas... lo cual te podrias evitar si ambas tablas estuviesen individual.

Que despejes datos a la hora de estructurar no implica que sea redundante algo, redundante es que despues te afecte indirecta o directamente la construccion de algo.  Pero mientras mas despejes aveces mas te puede convenir. Aunque visualmente parece que posee detalles demas el diagrama de Napk el meramente ha despejado tablas para evitarse problemas futuros de relacion, sobre optimizaciones de consultas es otro temita que se trata luego que tengas disenada las estructuras de tus tablas y mientras mas despejes mejor porque asi puedes decidir asignarles el motor conveniente a cada tabla sin necesidad de afectar a otra...  :-*