Problemas con llaves principal y foranea

[migferpedia77]

Hola a todos, estoy realizando una base de datos mas o menos larga, formada por cuatro tablas, necesito que todas estén relacionadas entre si y al crear las llaves principal y foranea y hacer las relaciones me presenta problema al insertar datos desde el formulario y no inserta los datos, cuando quito las llaves si me deja hacer la inserción de datos desde el formulario.
Estoy colocando en la primera tabla que es la de los datos personales la llave principal es un campo INT que autoincrementa y por ejemplo en la segunda tabla coloco la llave foranea al campo de numero de identificación haciendo referencia a la llave principal de la primera tabla, no se si es la referencia o es el hecho de crear las claves.
La DB esta con motor de almacenamiento MyISAM pero cada tabla esta como InnoDB, no se si eso también pueda estar afectando.

Bueno, en lo que me puedan colaborar, les agradezco de antemano.

BENDICIONES

[quimfv]

La DB esta con motor de almacenamiento MyISAM pero cada tabla esta como InnoDB, no se si eso también pueda estar afectando.

Si las tablas son InnoDB luego la bbdd es InnoDB...

Si en la tabla principal tienes solo un registro, y este tiene PK=1 para poder insertar algo en la secundaria debes ponerle ese 1 en el campo que referencia a la PK.....o nulo si no esta relacionado, lo que no puedes hacer es poner un valor que NO este en la principal.

Es lo que estas haciendo?

[migferpedia77]

Tengo una pregunta, mi base de datos la dividí en 4 tablas por que es un poco grande, pero todas las tablas obtienen los datos de un solo GRAN formulario html, mi pregunta es, como toda la información que llevo a mi base de datos es de un mismo formulario, la base de datos debería ser de una sola tabla con todos los campos en ella y será por eso que mis llaves principales y foráneas no funcionan bien o no tiene nada que ver en cuantas tablas coloque la información que obtengo de un formulario.

Bueno espero hacerme entender, y de paso por favor recomiendame una buena pagina donde pueda aprender a fondo sobre bases de datos mysql.

[quimfv]

...mi base de datos la dividí en 4 tablas por que es un poco grande...

El numero de tablas no ha de depender de lo "grande" que sea tu bbdd.

Habria que definir "grande".

El numero de tablas depende de la estructura de datos no del numero de datos. Es decir puedes tener una base de datos de telefonos (nombre, telefono) que se estructurará en una sola tabla tenga el numero que tenga de registros. Para que sea eficiente particionar, que no dividir, una tabla con esa estructura tendriamos que hablar seguramente de varios milloes de registros. Esa base de datos es "pequeña" (el termino adecuado seria "simple") si nos fijamos en la esteructura y puede ser muy "grande" si llegamos a los billones de registros (nombre,telefono).

Que los datos vengan de un formulario o muchos tampoco nos dice nada, o muy poco, de la estuctura de los datos ni por tanto del numero de tablas necesario.

Que los datos provengan de un formulario tampoco debe interferir en el funcionamiento de las pk y las fk...si se hace bien.

En definitiva NO das suficiente información para poder ayudarte.

[migferpedia77]

Hola...

Gracias por tus respuestas y tu colaboración, te voy a colocar algunas imagenes de mi bbdd.


Esta es la tabla 1

Base de datos: campakids Tabla: datoskids "InnoDB free: 4096 kB"

Campo Tipo Cotejamiento Atributos Nulo Predeterminado Extra Acción

kidNumId int(10) UNSIGNED No auto_increment
kidId int(10) No
kidFecha date No
kidName varchar(100) utf8_general_ci No
age int(2) No
altura float No
talla varchar(1) utf8_general_ci No
padre varchar(100) utf8_general_ci No
madre varchar(100) utf8_general_ci No
numTel int(10) No
numCel int(10) UNSIGNED No
email varchar(100) utf8_general_ci No

Esta es la tabla 2

Base de datos: campakids Tabla: consent "InnoDB free: 4096 kB"

Campo Tipo Cotejamiento Atributos Nulo Predeterminado Extra Acción
kidId int(10) UNSIGNED No
kidName varchar(50) utf8_spanish_ci No
consent1 varchar(3) utf8_spanish_ci No
consent2 varchar(3) utf8_spanish_ci No
consent3 varchar(3) utf8_spanish_ci No

Esta es la tabla 3

Campo Tipo Cotejamiento Atributos Nulo Predeterminado Extra Acción
kidId int(10) No
kidParentName varchar(100) utf8_general_ci No
dadHomePhone int(10) No
dadofficePhone int(10) No
dadCelPhone int(10) No
erContact1 varchar(100) utf8_general_ci No
erPhone1 int(10) No
erCel1 int(10) No
erContact2 varchar(100) utf8_general_ci No
erPhone2 int(10) No
erCel2 int(10) No
kidEps varchar(50) utf8_general_ci No
kidEpsCotiz varchar(100) utf8_general_ci No
kidDeseases varchar(200) utf8_general_ci No
kidOtherDes varchar(200) utf8_general_ci No
kidAllergies varchar(200) utf8_general_ci No
kidAllergiesEspec varchar(200) utf8_general_ci No
kidAnotherDes varchar(200) utf8_general_ci No
kidMedicalCare varchar(3) utf8_general_ci No
kidMedExam1 varchar(50) utf8_general_ci No
kidMedExam2 varchar(50) utf8_general_ci No
kidMedExam3 varchar(50) utf8_general_ci No
kidHospCare varchar(3) utf8_general_ci No
kidPhisAct varchar(3) utf8_general_ci No
kidPhisActEspec varchar(200) utf8_general_ci No
kidDrugs varchar(3) utf8_general_ci No
kidDrugsEspec varchar(200) utf8_general_ci No
kidMedCond varchar(200) utf8_general_ci No
kidMedCondEsp varchar(200) utf8_general_ci No
kidInfection varchar(3) utf8_general_ci No
kidInfecEsp varchar(200) utf8_general_ci No
kidGenCond varchar(200) utf8_general_ci No
kidDoctor varchar(100) utf8_general_ci No
kidDocPhone int(10) No
kidPhysical varchar(3) utf8_general_ci No
kidPhysEspec varchar(200) utf8_general_ci No
kidPhisFinal varchar(3) utf8_general_ci No
kidPhysFinalEsp varchar(200) utf8_bin No

Y otra tabla 4 mas o menos del mismo tamaño de la 3.

Mi pregunta o problema en cuestión es el siguiente, tengo un solo formulario como ya dije y este se divide en 4 partes que cada una llena datos a una de estas tablas. necesito que todas las tablas se comunique entre si, es decir que al hacer consultas o busquedas yo coloque los datos de un niño (esta es informacion de niños de un campamento), pueda hacer consultas de las otras tablas y obtener información de cada tabla solo colocando el nombre o el numero de identificación; yo creo que colocando llaves foranes y principales lograre esto, no se si estoy equivocado o si hay otra forma, lo otro es colocar en cada tabla un campo para el numero de identificación, es decir que se repita en cada tabla para poder hacer consultas individuales en cada tabla.
En fin ese es mas o menos mi problema, así que si puedes darme una luz en mi ignorancia te agradecería y de paso decirme donde puedo comprender a fondo sql sería aún más grandioso.

[gnzsoloyo]

donde puedo comprender a fondo sql

Estás confundiendo temas... El problema que no conoces, no es el SQL (que en sí es un lenguaje de consultas y no una base de datos), sino los fundamentos del diseño de bases de datos, que es un tema totalmente distinto, y para el cual hay que conocer algo de Análisis de Sistemas, más que de SQL.

El SQL es una herramienta para hacer consultas, pero mucho antes de eso se debió diseñar el modelo de datos. Allí es en el modelado de datos donde te falla el tema, por lo que se alcanza a entender.

El hecho de que tengas cuatro (4) formularios no es relevante, porque podrías tener 35 formularios, que solamente necesitaran seis (6) tablas (caso que he tenido), o bien tener un sólo formulario y afectar 57 tablas... como uno en el que trabajo ahora.
Lo que quiero que te quede claro es que no es lo mismo lo que ve el usuario y lo que programas en la aplicación con lo que se necesita en estructura de bases de datos para darle soporte a todo eso.
Una factura, por dar un ejemplo, sólo requiere un formulario, y aparentemente no más de cuatro o cinco tablas.
Pues eso es un error. Para poder emitir una sola factura se pueden requerir más de treinta tablas, dependiendo de muchos factores, porque una enorme cantidad de cosas que se pueden inferir del problema afecta estructuras que son invisibles para el usuario.

En tu caso, esa sola tabla que ves al final, tan extensa, tiene no sólo datos redundantes, y que no deberían esta allí, sino además tiene una enorme falta de normalización que será difícil de resolver, sin tener que descartar tu modelo para empezar de nuevo.

Para darte una idea:
Enfermedades, Alergias, Examenes, Medicamentos (drogas es una subcategoría, no una entidad propia), CondicionesMedicas, Infecciones, son todas entidades separadas y no atributos de una única tabla. Se vinculan en la de HistorialMedicoKid (que no has creado).
Faltan las tablas de HistorialMedico, las relacionales, las de Familiares, Telefono, MedicalCare (sistema medico del niño), Contactos, etc. Todas son entidades separadas, que se relacionan en un sistema complejo.
En el caso de los datos del niño en cuestión, Talla y Altura son datos redundantes según el país, ya que son sinónimos, y si se pone la fecha de nacimiento, la edad es irrelevante (se hace por cálculo), No se deben poner nombres de padres o madre, sino que eso surge de una tabla relacional entre Niño y Famila (Tabla Kid_Familar), donde también puede aparecer un atributo que diga "vínculo", o bien eso es una tabla paramétrica fija relacionada.

Creo que con lo que te estoy diciendo, ya te puedes ir dando una idea de que para ser una base de datos eficaz y eficiente, lo que tienes no sirve.
Pero todo dependerá de lo bien que quieras trabajar y cuánto desees aprender.

Mira este modelo, que sólo incluye los datos básicos:


Y esto sería un modelo de aplicacion para pacientes médicos:



Ahora trata de imaginar algo que combine ambas cosas y te estarás acercando...

[quimfv]

Para afrontar lo que te planteas debes separar las distintas entidades, en primer caso tines los kid, lugo los parientes de estos.....las enfermedades....

Piensa si tienes dos hermanos en el campamento, no es eficiente guardar dos veces los datos de los padres, con la estructura que planteas no tines mas remedio que guardarlos dos veces. Eso ademas de ineficiente des del punto de vista de espacio en disco complica mucho el mantenimiento de la bbdd imagina que un niñ@ te reporta que su familia ha cambiado de direccón.... tendras que hacer el cambio para el niño y para todos los posibles hermanos.... si encambio tienes la dirección familiar en una tabla aparte solo deberás cambiarla en esa tabla sin preocuparte de cuantos hermanos haya en la familia, el cambio sera efectivo para todos...(cada niño debe tener una FK a su familia).

Ese mismo ejemplo es aplicable a una enfermedad o alergia, dos niños con la misma enfermedad, por que guardar dos veces los datos de la enfermedad. I así con todas, o casi todas, las caracteristicas de cada niñ@...


Bien venido al mundo de las bases de datos relacionales.

[migferpedia77]

Oye gracias a todos por esta invaluable ayuda me ha esclarecido mucho acerca de las bases de datos, pero, aun por favor perdonen mi lento aprendizaje, pero al crear cada tabla de forma creo eficiente, viene de nuevo el tema de las llaves principales y foráneas, es decir que reglas o guías tengo que seguir para crearlas, que parámetros tengo que seguir para que cada llave funcione correctamente y no afecte el ingreso de datos cuando este enviando el formulario, por que de nada vale crear muchas tablas y no poder relacionarlas correctamente.

Nuevamente GRACIAS por toda su colaboración y la información que he obtenido y sueño que algun día pueda entrar al selecto y grandioso mundo de los programadores.

Cualquier información sobre las llaves foráneas sería excelente y algún sitio web donde pueda ahondar en todo este tema.

[quimfv]

Las reglas básicas, son:

El campo de enlace debe ser del mismo tipo de datos que el campo referenciado (ojo si el referenciado es autoinc es un numérico (INTEGER o LONG), el atributo autoinc no tienen nada que ver.

El campo referenciado debe ser único (PK o índice único) en la tabla referenciada.

Toda FK debe contener un valor que exista previamente en el campo referenciado o ser nulo (si le es permitido serlo).

Esas son las reglas luego la coherencia de las FK solo la puedes saber tu que conoces lo que quieres hacer.


http://dev.mysql.com/doc/refman/5.0/...nstraints.html

Por cierto tus tablas deben ser innodb