Coherencia BBDD

dr_Rouman #1 Nov '10

Tengo una duda bastante estúpida con bases de datos, pero como hace 1000 que no lo pruebo, pues no tengo ni idea.

El ejemplo no es real y puede que no tenga sentido, sólo quiero que se entienda la situación con las claves y las participaciones mínimas. Vamos a ver, si yo tengo dos tablas Persona y Trabajo, y Persona tiene un FK not null de Trabajo y Trabajo tiene un FK de Persona not null...¿cómo se inserta eso en la base de datos?

Si inserto una antes que otra, la foreign key de la primera que se inserte no se puede definir hasta que no se cree la otra. Lo único que se me ocurre es que si yo hago los insert pero no hago el commit no hay problema ninguno, pero es que no lo sé, la verdad xD

Mi gran problema es que la última vez que trabajé con bases de datos fue con Python + Django y ahí era bastante más sencillo todo xDD

Por si ayuda, me refiero a Oracle.

Un saludo y gracias

B

[Borrado] #2 Nov '10

Digo esto desde la ignorancia, ya que tengo una practica de esto para la próxima semana y aun no he empezado, asi que no he tenido que hacer nada así. No puedes crear una tabla sin la fk, crear la otra definitiva, y luego modificar la primera?

cabron #3 Nov '10 Judas

Si una persona puede tener varios trabajos, y el mismo trabajo puede ser de varias personas, es una relación de varios a varios, y las realaciones de varios a varios se resuelven con una tabla intermedia, que no tiene por que tener atributos propios, puede servir solo para mantener las relaciones, es decir, que tendrá dos columnas, una para cada clave primaria de las dos tablas.

Cuando quieras relacionar una persona con un trabajo (o al revés), insertas el registro en la tabla intermedia, metiendo la clave primaria de los registros de cada tabla que quieras relacionar.

Buffoncete #4 Nov '10 Inocente

lo que dice #3

normaliza antes de generar la bbdd

Elektr0_ddr #5 Nov '10

#3 Imagina que una persona tiene que tener al menos 1 puesto de trabajo y todo puesto de trabajo debe tener al menos una persona.
Puede ser una relacion N-M, pero querer tu restringir a nivel de BD que no se incumpla esta condición. Para este tipo de casos en los que para insertar "una cosa" necesitas "otra" y viceversa se usa en Oracle la clausula DEFERRABLE INITIALLY DEFERRED para que la FK se compruebe en el commit de la transacción, en vez de comprobarse de manera inmediata.

eXtreM3 #6 Nov '10

ALTER TABLE es tu amigo

Tuve que hacer un caso parecido en una práctica, que la tabla A necesitaba foránea de tabla B, y tabla B necesitaba foránea de tabla A. La única manera de hacerlo fue mediante alter table

dr_Rouman #7 Nov '10

Era más bien lo de #5, no me he expresado muy bien.

Muchas gracias, voy a echar un vistazo a eso

Elektr0_ddr #8 Nov '10

#6 Como ya he dicho en #5, en Oracle existe un mecanismo que justo está diseñado para ese problema, para no andar haciendo chanchullos con ALTER TABLE y son las claves foraneas diferibles, en MySQL por ejemplo no existen las FK diferibles, pero en Oracle sí.

Edit: Juas, ya se ha aclarado entonces xD

eXtreM3 #9 Nov '10

Es bueno saberlo

Buffoncete #10 Nov '10 Inocente

#8 pero todas esas cosas tan chulas que ofrece oracle que te permite diseñar tu BBDD en NF1 implican una velocidad menor luego.

Sino mirad Oracle worst practices:
http://www.dba-oracle.com/t_worst_practices.htm

edito:
me he releído y parece un post agresivo cuando no lo es

Usuarios habituales