Una orientacion para Aplicacion MySQL

[*Caro*]

Hola karlaoax, yo creo que deberias tener 2 tablas una de pacientes y otra de visitas, en pacientes estarian todos los datos generales de tu paciente y en visitas todas las visitas que realiza el paciente al consultorio

PACIENTES(RFC, NOMBRE,....)
VISITAS(FECHA_VISITA,......,RFC)

y estarian relacionados con tu campo RFC

Saludos

[karlaoax]

Empezado por Caro

Hola karlaoax, yo creo que deberias tener 2 tablas una de pacientes y otra de visitas, en pacientes estarian todos los datos generales de tu paciente y en visitas todas las visitas que realiza el paciente al consultorio

PACIENTES(RFC, NOMBRE,....)
VISITAS(FECHA_VISITA,......,RFC)

y estarian relacionados con tu campo RFC

Ok gracias, pero recuerda que si hago esta opcion en mi tabla VISITAS tendria mi RFC como clave primaria, el problema es que si me visita el 15 Junio, lo guarda bien, pero si me visita el 17, como ya se almaceno su RFC en la tabla, mi pregunta es, como guardar, En fechas diferentes para un mismo registro

Si hago la opcion que me dijiste me marcaria Key Violation, porque ya existe un registro con el mismo RFC,,,,,,,,,,,,, Gracias

[*Caro*]

No tendrias ese problema porque solo en tu tabla de Pacientes tu campo RFC seria tu llave primaria pero en tu tabla Visitas tu RFC seria una llave foranea que significa que se puede repetir, la relación entre estas tablas seria de de 1 a muchos.

[karlaoax]

Ok gracias CARO por la orientacion voy a hacer una prueba para ver como queda.

Los voy a unir por medio de SQL al momento de hacer las consultasy presentar en pantalla los resultados.
Karla

[roman]

Yo te recomiendo que no uses el RFC como llave primaria. En general, no deberían usarse campos que tengan un significado práctico como llaves primarias. Si por error registras un paciente con un RFC incorrecto, tendrás que liarte con la corrección en todas las tablas que usen ese RFC como llave foránea. Siguiendo lo delineado por Caro, yo usaría esta estructura:

+---------------------------------+
|           pacientes             |
+----+-----+--------+-------------+
| id | rfc | nombre | otros datos |
+----+-----+--------+-------------+
|    |     |        |             |
| pk |  uk |        |             |
|    |     |        |             |
|    |     |        |             |
+----+-----+--------+-------------+

+--------------------------+
|          visitas         |
+----+-------------+-------+
| id | paciente_id | fecha |
+----+-------------+-------+
|    |             |       |
| pk |      fk     |       |
|    |             |       |
|    |             |       |
|    |             |       |
|    |             |       |
|    |             |       |
|    |             |       |
|    |             |       |
+----+-------------+-------+

pk = llave primaria, uk = llave única, fk = llave foránea.

La llave primaria, sería un autoincremental.

// Saludos

[karlaoax]

Buen punto Roman, gracias, Ambas recomendaciones me serviran mucho para la creacion de este ejemplo.

Asi cuando guarde varios ID con sus respectivos RFC en mi tabla visitas, no me saldra el mensaje KeyViolation, y podre consultar sus fechas de visita cuantas veces sea necesario.

Gracias a ambos por sus sugerencias.

Karla

[roman]

Empezado por karlaoax

Asi cuando guarde varios ID con sus respectivos RFC en mi tabla visitas

Noooo. El RFC no se guarda en la tabla de visitas, sólo en la de pacientes. De lo contrario obtienes el mismo problema: un error en el rfc de un paciente te obliga a corregir todas las vistas de ese paciente. El RFC así como el nombre y demás datos de un paciente los obtienes al enlazar ambas tablas:

Código SQL [-]
select pacientes.rfc, pacientes.nombre, visitas.fecha
from visitas
left join pacientes on pacientes.id = visitas.paciente_id
...

// Saludos

[karlaoax]

sorry es que lo escibi mal, pero si, eso lo que voy a hacer je je je

gracias Roman