Muchas gracias a ambos, os respondo a continuación
Cita:
Iniciado por quimfv 
Quizas se podria optimizar creando una tabla usuarios donde se guardarian los datos de los usuarios, para futuras inscripciones eliminando repeticiones
Esto de la tabla usuario lo pensé, sería lo ideal, que el usuario se registrase y si se quiere apuntar a otro curso no tuviese que rellenar sus datos personales...
Evitando no tener que pedirle los datos cada vez que quisiese apuntarse a un curso, lo estudiaré, pero eso implica que luego deben poder modificar sus datos personales, direccion, telefono etc...
Y sobre lo que comentas
gnzsoloyo, coincido que se podría optimizar la tabla inscripciones dividiéndola en usuarios
Cita:
Iniciado por gnzsoloyo Estoy de acuerdo con quimfv, el modelo es en principio correcto. Posiblemewnte esta tabla sea bastante más optimizable:
Pero no acabo de entender el tema que mencionas de los telefonos.
Cita:
Iniciado por gnzsoloyo Sobre la base de la normalización, hay al menos dos tablas desprendiéndose de ella, como es el caso de los teléfonos, que en mi opinión deberían ir en otra tabla, unificando los profesionales, particulares y comerciales en una sola con un campo para distingir tipo.
Te refieres algo así? Pero como pones si los datos particulares o profesionales?
Código sql:
Ver originalCREATE TABLE contacto (
idcontacto INT NOT NULL,
telefono VARCHAR(10),
movil VARCHAR(10),
email VARCHAR(10),
}
Esto no lo entendí, prefijos? no hay prefijos, los datos
pref_tel_particular char(1) DEFAULT '0',
pref_tel_profesional char(1) DEFAULT '0',
pref_ema_particular char(1) DEFAULT '0',
pref_ema_profesional char(1) DEFAULT '0',
Son para saber porqué método desean ser contactados
Cita:
Iniciado por gnzsoloyo Además, poner los prefijos en otro campo no resulta funcional, ya que conceptualmente es parte del mismo número y no se debe hacer una atomización tan detallada.
Muchas gracias