disculpen por aparecer un poco tarde, la propuesta que yo hacía era para evitar forzar un valor NULL, podemos ver que en las filas de la tabla siempre va a haber un valor NULL, siempre! y eso no em muy bien visto en diseño conceptual del modelo. Solo para justificar mi propuesta :-)
Guillermo Villanueva El 23 de abril de 2014, 8:55, Laura Martinelli <[email protected]>escribió: > Gracias por tu respuesta, es lo que creo mejor va a funcionar para lo que > necesito. > Muchas gracias a todos. > > Saludos, > Laura Martinelli. > El 22/04/14 16:30, Luis Ramon Sanchez Rico escribió: > >> Hola laura, te recomiendo que quites las llaves foráneas y las >> implementar tú, podrías naves una función que se dispare como trigger, >> cuando necesites hacer operaciones que vayan a checar las llaves foráneas, >> le pases como parámetro a la función si es un taller o una materia y con >> ese parametro hagas una consulta a la tabla, taller o materia buscando la >> existencia de la llave, si no existiera detendrias la ejecución y mandarlas >> un mensaje de que se viola la llave. Y si se encontrara la llave en la >> tabla correspondiente si realizara la operación indicada. Así tendrías tu >> función que checaria la llave foránea y podrías borrar las que se ponen por >> el manejador >> > > > > __________ Information from ESET Mail Security, version of virus signature > database 9710 (20140423) __________ > > > The message was checked by ESET Mail Security. > http://www.eset.com > > > > - > Enviado a la lista de correo pgsql-es-ayuda ([email protected] > ) > Para cambiar tu suscripción: > http://www.postgresql.org/mailpref/pgsql-es-ayuda >
