Clave Foraneas, no puedo agregar filas

[HiToGoRoShi]

Código MySQL:

Cannot add or update a child row: a foreign key constraint fails (`peruguitar`.`comunidad`, CONSTRAINT `fk_comunidad_usuario1` FOREIGN KEY (`idUsuario`) REFERENCES `usuario` (`idUsuario`) ON DELETE NO ACTION ON UPDATE NO ACTION)
 
INSERT INTO `peruguitar`.`comunidad` (`idUsuario`, `nombre`, `descripcion`, `fechaCreacion`) VALUES (2, 'asdasd', 'asdasd', 0)
 

No puedo agregar filas, nose porque en mi tabla Usuario existe el usuario con el id 2, el cual soy yo, intento agrearlo y me sale esto.

PD: la tabla es InnoDB

[gnzsoloyo]

En principio, el esquema de relaciones parece mal planteado, y existen dependendias que no deberían ser tales.
Me explico: Si tienes Usuarios, Comunidades, Grupos, Artículos, y Comercios, se puede decir que un usuario puede pertenecer a una comunidad o ser fan de ella, pero la tabla Comunidad no debe llevar el ID del usuario, porque el la comunidad es independiente del usuario. Como entidad es autónoma. Con la comunidad los usuarios tienen una relación N:N que significa que debe haber una tabla adicional que administre esa relación, pero la relación sólo existe a través de esa tabla. No existe una relación directa con Comunidad.
Lo mismo corre para grupos, Artículos, Comercios y todo lo demás.

Revisa tu diseño.

[HiToGoRoShi]

En realidad lo que decia, es que un Usuario puede crear una comunidad ... y varios pueden unirse a ella o ser fans, como tambien peuden dejar comentarios a cada comunidad, casi la misma logica se aplica para comercio, articulos ... se entiende mejor como lo plantie? o igual hay fallas...

Y econtre el error, estaba en innodb mi tabla, y la otra era MyIsam

[gnzsoloyo]

Si el usuario crea la comunidad deberías ponerlo como moderador de la misma. Sería un mejor planteo. De todos modos, en tu diagrama no está puesta la relación de los usuarios como partícipes o asociados a la comunidad, o el grupo.
En otras palabras, Si un usuario crea la comunidad, y entra como moderador de la misma, entonces hay una relación 1:1 entre el usuario creador y la comunidad. En ese caso la FK va en la comunidad, pero sólo significa eso: Es el moderador.
Pero a su vez, hay una segunda relación, esta vez N:N entre la comunidad y los usuarios, que determina si es participante. Esa requiere otra tabla pero vinculada a ambas, donde la PK es la PK de cada tabla. Esta relación no la veo graficada en tu diagrama.
¿Se entiende?
Luego, si es partícipe, Fan, asociado o simpatizantes, en definitiva son diferentes categorías de asociación, pero no requerirían necesariamente una tabla por si mismas, a menos que ser una cosa o la otra implique atributos (columnas) diferentes para datos específicos. Si sólo va a ser un valor, entonces puede manejarlo con una columna ENUM o SET en la misma de la asocaición, y no necesariamente con una tabla.

El esquema de Grupos, Comunidades, o cualquier otro nodo social que desees crear sigue siempre más o menos el mismo esquema.

Mirado de esta forma, el modelo necesitaría ciertos ajustes, ¿qué te parece?

[HiToGoRoShi]

Me has confundido un poco, a ver yo lo veo asi ... un Usuario creo una comunidad, y otros usuarios pueden unirse a la comunidad... Comunidad y Comunidad Fan se realacionan por idComunidad, comunidad se relacion con idUsuario con la tabla Usuario, y ComunidadComentario, tambien se relaciona con el idComunidad de la tabla comunidad ... ahi me parece que ya estan relacionados ..

[gnzsoloyo]

La relación entre Usuarios y FanComunidad no es transitiva. No existe la transitividad entre entidades no dependientes en bases de datos.
El DEr de una bases de datos no es igual al DER de Analisis de Sistemas. Los conceptos del diseño son levemente diferentes.
En tu diagrama, la Relación entre el usuario suscripto como Fan y la tabla Usuarios se da exclusivamente por medio de la tabla Comunidad, lo que significa que para suscribir un usuario en FanComunidad, primero ese usuario tiene que haber creado una Comunidad, y sólo se puede suscribir si su ID está en la tabla Comunidad. Eso implicaría una dependencia funcional de ambas tablas, y no es lo que quieres hacer.
Para estblecer cuáles son las relaciones tendremos que volver a la semántica de las mismas:
- "Un usuario Puede crear una o más comunidades, pero cada comunidad sólo puede ser creada por un único usuario" (relación 1:n entre ambas entidades).
- "Una comunidad puede tener uno o muchos seguidores y cada seguidor puede serlo de diferentes comunidades" (relación N:N entre ambas tablas)
- "Cada usuario de la comunidad puede hacer múltiples comentarios en la comunidad y cada comentario le pertenece a un un solo fan" (relación 1:N entre ComenarioComunidad y FanComuidad, es una relación dependiente de una entidad relacional).

¿Se percibe cómo se visualizan las relaciones en forma de frase? Al hacerlo así, las entidades se vuelven más definidas y también las dependencias.

Vamos a un ejemplo práctico (Database Answers):

Este tiene algunos detalles emparentados con tu problema.

[HiToGoRoShi]

asi lo tengo, en relacion uno a muchos

[gnzsoloyo]

ComunidadFan no es una tabla dependiente de esa forma sino una tabla relacional producto de la relación N:N entre Comunidad y Usuarios. Lo mismo sucede con GrupoFan. No te lo grafico porque en este momento no tengo tiempo de hacerlo; si quieres pasar el archivo de WB, te lo replanteo y lo devuelvo.
Si lo planteas de esa forma tendrás problemas en las inserciones.

[gnzsoloyo]

Esto es lo que mas o menos yo te planteo:


Notarás que tiene leves diferencias, pero esas diferencias son fundamentales para el modelado de esta base.

La última tabla no sé que representa y tampoco cómo encaja en el modelo.

[HiToGoRoShi]

Aca esta mi diagrama
http://www.megaupload.com/?d=6J13JQ42

Voy a estudiar lo que me plantiaste, y tratare de hacer el diagrama como tu lo dices .. a ver si luego comparamos nuestors reusltados y pensamos igual

[gnzsoloyo]

Gracias por el paquete. Con eso hay algunos cuantos detalles que sugeriría que reconisderes y algunas cosas que no se entiende qué son o cómo se relacionan.

Las tablas:

- PG_ARTICULO_TITULO
- PUBLICACION
- ARTICULO
- OPORTUNIDAD
- COMERCIO

No se comprende qué representan exactamente o qué relación hay entre ellas. En el caso de las dos últimas da la impresión de que los nombres están colocados y que la relación surge de una normalización mal creada, ya que algunos atributos de la última parecen pertenecer a otra cosa.

Otro detalles son las fechas. Salvo por razones muy específicas (usar unixtime, por ejemplo), las fechas deben ir en DATE, DATETIME o TIMESTAMP, pero no deben ponerse como INT o VARCHAR. Si las fechas se usan como unixtime corresponde entonces que uses BIGINT UNSIGNED y no un simple INT, ya que el unixtime representa el entero sin signo de segundos entre 1970 y la actualidad. Como ese entero no tiene signo debes usar una columna sin signo.
No se usan VARCHAR porque las fechas se deben almacenar en su formato natural (aaaa-mm-dd hh:mm:ss) y no como cadenas. Si luego necesitas la fecha en un formato especial, simplemente usas DATE_FORMAT() o bien lo haces en la aplicación con number_format() si usas PHP. Pero no lo haces en la tabla de la base.

Con las modificaciones restantes según mi planteo quedaría así:

[HiToGoRoShi]

Gracias por tu ayuda .... hice algunos cambios en mi modeladooo pero ahora tengo otro problema


No puedo exportar el diagrama a la base de datos, me vota un error, usuario y articulo son INNODB, porque no puedo exportarlo ?, que hago mal

Aparte, unas dudas la tabla dependiente siempre debe tener update y deleted en cascada ?, y ambas deben ser innodb para que funcione la relacion ?, o puede ser innodb solamente la tabla dependiente ..

Código MySQL:

Executing SQL script in server
 
ERROR: Error 1005: Can't create table 'peruguitar.articulo' (errno: 150)
 
 
 
 
 
CREATE  TABLE IF NOT EXISTS `peruguitar`.`articulo` (
 
  `idArticulo` BIGINT(20) NOT NULL AUTO_INCREMENT ,
 
  `idUsuario` BIGINT(20) NOT NULL ,
 
  `titulo` VARCHAR(60) CHARACTER SET 'utf8' COLLATE 'utf8_spanish_ci' NOT NULL DEFAULT 'Sin titulo' ,
 
  `descripcion` TEXT CHARACTER SET 'utf8' COLLATE 'utf8_spanish_ci' NOT NULL ,
 
  `imagen` VARCHAR(50) CHARACTER SET 'utf8' COLLATE 'utf8_spanish_ci' NULL DEFAULT 'default.png' ,
 
  `valoracion` FLOAT(5,2) NULL DEFAULT '5.00' ,
 
  `lectura` INT(10) NULL DEFAULT '0' ,
 
  `fechaCreacion` BIGINT(20) NOT NULL DEFAULT '0' ,
 
  PRIMARY KEY (`idArticulo`) ,
 
  INDEX `fk_articulo_usuario1` (`idUsuario` ASC) ,
 
  CONSTRAINT `fk_articulo_usuario1`
 
    FOREIGN KEY (`idUsuario` )
 
    REFERENCES `peruguitar`.`usuario` (`idUsuario` )
 
    ON DELETE CASCADE
 
    ON UPDATE CASCADE)
 
ENGINE = InnoDB
 
AUTO_INCREMENT = 1
 
DEFAULT CHARACTER SET = utf8
 
COLLATE = utf8_spanish_ci
 
 
 
SQL script execution finished: statements: 3 succeeded, 1 failed
 

PD: respecto a los demas que me decias, voy a trabajar con unixTime, y los campos de varchar que viste no los cree yo, era de un sistem antiguo que toy migrando.. saludos

[gnzsoloyo]

Detalles:
1) Asegúrate de que TODAS las tablas son InnoDB. En el diagrama que pusiste para descargar había al menos dos que no lo eran.
2) Asegúrate de que todo valor que no sea FLOAT sea UNSIGNED. Usarlos sin esa indicación hará que el rango de representación se reduzca a la mitad, y en el caso de los UNIXTIME te dará error de dato truncado al insertar.
3) Asegúrate de que las columnas relacionadas como FK sean del mismo tipo y rango en ambas tablas. Cualquier diferencia entre ambas generará un error, y MySQL Workbench no las verifica a menos que la inclusión de la FK haya sido hecha automáticamente por diagrama, usando el conector de la barra de herramientas.
4) La decisión de poner o no CASCADE la toma el diseñador del sistema. No hay una regla general, depende del caso específico, al punto tal que la decisión de ponerla puede no abarcar a toda la base, sino tan sólo alguna o algunas tablas, y nada más. Tiene que ver con la necesidad de mantener la integridad de datos.
Un momento en que se da esto sería si tienes tablas donde esa PK se almacene, pero no se declaren relaciones de FK (usar tablas InnoDB y MyISAM al mismo tiempo es un ejemplo). En ese caso no se puede permitir el CASCADE porque sólo actualizaría el valor de las tablas relacionadas que sean InnoDB y tengan FK, pero no se actualizarían las otras; entonces, por seguridad de consistencia en los datos, no se puede permitir que el UPDATE se realice en cascada.

Finalmente: No me has contestado lo que te pregunté respecto a esas tres tablas cuyo sentido, representación y relaciones no se comprende. Analizándolas parecen estar diseñadas incorrectamente a partir de una normalización inadecuada.

[HiToGoRoShi]

A ok, un usuario crea una oportunidad .... que son las oportunidades, son oportunidades de hacer negocio en la web ... por el momento hay 2 oportunidades, Comercio y Anuncios .... pero ambas son relacionadas a la tabla oportunidad ...

Es decir:

Oportunidad -- > Comercio
Oportunidad -- > Anuncio

Donde ambas se relacionan por su ID, asi yo te un golpe puedo controlar las oportunidades dirigiendome solamente a mi tabla oportunidad, y si borro ahi una oportunidad la relacion en cascada se encarga del resto ..

Ahora la tabla que dice pg_articulo_titulo, todavia no la e migrado, va relacionada a publicacion, es el titulo de cada publicacion (de un sistema antiguo que usaba, el phpBB). Pero ahora no lo pienso hacer asi, lo voy a hacer creando una tabla Recursiva sin titulo, ya que seria algo asi el usuario genera una publicacion en su perfil, y esta puede ser comentada, ahi juego con la recursividad (tara bien dicho esa palabra?) xD

[HiToGoRoShi]

Que tal amigo, sigo con el mismo problema, solo cuando le quito la relacion funciona bien, de otro modo no funciona .. :S

Te adjunto mi diagrama

http://www.megaupload.com/?d=6KNXAC7D

PD, mi tabla usuario ya tiene registros tendra algo que ver eso ¿

[gnzsoloyo]

En tu diagrama hay todavía una tabla que es MyISAM, donde quieres poner FK: Publicacion

[gnzsoloyo]

Pero ahora no lo pienso hacer asi, lo voy a hacer creando una tabla Recursiva sin titulo, ya que seria algo asi el usuario genera una publicacion en su perfil, y esta puede ser comentada, ahi juego con la recursividad (tara bien dicho esa palabra?) xD

Las relaciones recursivas quedan muy bonitas en el diagrama, pero en las consultas producen dolores de cabeza.
Parecen simples, pero cuando luego quieres hacer una consulta que te devuelva la totalidad de posts, y respuestas a los posts tienes el problema de la indeterminación de niveles de respuesta, cada una de los cuales implicará un JOIN encadenado.
Parece simple, pero en ese caso tienes que crear dinámicamente los JOIN o hacer subconsultas anidadas hasta el límite de las vinculaciones. A mi, personalmente, me parece complicar demasiado las cosas, cuando haciendo dos tablas y un sólo JOIN podrías obtener todas las respuestas por orden cronológico, o el que sea, sin ningún problema.
No te olvides que MySQL no tiene funciones recursivas, por lo que no puedes usar SP ni SF para obtener eso.
Yo lo haría con dos tablas: PostsGrupo y ComentariosPosts. Una relaciín 1:N y ya está.

[HiToGoRoShi]

Listo colega, mi db ha quedado ahora a asi



Curiosamente el workbench no esta mostrando las lineas en anuncio, y comercio, pero ambas estan relacionadsa a oportunidad ... tiene muchos bugs el WB, en algunos casos que no podia crear la relacion tuve que borrar la tabla y volverla hacer

[gnzsoloyo]

¿Creabas las relaciones gráficamente o las indicabas en las propiedades?
Hacerlo gráficamente siempre es mejor...

[HiToGoRoShi]

Todo lo hago graficamente