Tu creas la tabla clientes



Ahora me creo la tabla facturas que tenga integridad referencial con la anterior y que se pueda borrar en cascada en una base de datos BASE


Y eso es todo. Lo importante es la línea index (debe estar indexada) y la línea foreign ... Si no le pongo lo del on delete cascade entonces las reglas de integridad referencial impiden eliminar registros que no cumplan la integridad.

Las tablas deben ser de tipo innodb.

 

Podeis contarme que es la:

Citar:

integridad referencial

Gracias.

Nota:
Supongo que si por ejemplo borras una factura, el descompuesto de esa factura (que estaria en otra tabla) se debería borrar tambien para mantener esa "integridad" ¿no?

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!

hola

Imagina que haces una aplicación de clientes y facturas. Con toda seguridad habrá clientes que no tengan ninguna factura aunque solo sea porque los acabas de meter y aún no tienen ninguna, pero lo que no es posible es lo contrario. No es posible que haya una factura que no sea de ningún cliente.

La integridad referencial quiere decir que tu puedas relacionar dos tablas y establecer una regla entre ellas de tal forma que no sea posible que haya facturas sin cliente. Da igual lo que hagas en la aplicación. Antes o despues de una forma u otra los datos que metes o cambias van a la base de datos y esas reglas son a nivel de base de datos y aplicadas por el gestor de base de datos.

Imagina que tengo al cliente con dni XXX y las facturas en otra tabla donde dice que el codigo del cliente es XXX. Si un día modificas la factura por cualquier razón y cometes un error cambiando XXX por otra cosa no te dejará a menos que esa otra cosa exista. Si quieres borrar un cliente no te dejará si ese cliente tiene facturas porque quedarían facturas sin cliente.

Eso es la integridad referencial.

Opcionalmente se puede decir que borre en cascada. Esto quiere decir que si borras un cliente, el gestor de base de datos borre todas las facturas de ese cliente y si modificas al cliente se modifica el código en todas las facturas del cliente.

Como ves no tiene que ver con extraer datos de varias tablas sino asegurarse que los datos en ellas son consistentes.
 

Ok, gracias Soplo

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!

Hola, yo utilizo postgresql sobre todo porque soporta la integridad referencial y porque utilizo bastante consultas con campos calculados y en las pruebas que hice en consultas con 90000 registros (la misma consulta en mysql con InnoDB y postgresql ) en  postgresql tardaba como 10 o 20 veces menos en devolver los registros, por eso me decidí por postgresql y también que postgresql  es libre, mysql es propiedad de Oracle.

En cuanto a las relaciones es fundamental pensar bien el diseño de la base de datos  para la coherencia de los datos.

Por ejemplo un cliente puede tener muchas facturas, pedidos, albaranes etc. seria un desastre (creo yo) poner eliminaciones en cascada, puedes borrar el cliente y automáticamente te borraría todos los albaranes, facturas.

Aquí tienes bastante bien explicado la integridad referencial  http://www.postgresql-es.org/node/249

Es en postgresql pero es aplicable a mysql.

Yo utilizo navicat para diseñar las consultas es bastante sencillo, parecido a ACCESS , tienen una versión trial  operativa durante 30 dias
otra versión libre, facil de instalar (operan sobre wine) y version para postgreql y mysql.

Citar:

Por ejemplo un cliente puede tener muchas facturas, pedidos, albaranes etc. seria un desastre (creo yo) poner eliminaciones en cascada, puedes borrar el cliente y automáticamente te borraría todos los albaranes, facturas.

No estoy de acuerdo. Yo siempre establezco las relaciones en cascada cuando deben ser establecidas.
Por ejemplo, si tienes la tablas de Clientes, Facturas y Materiales, puedes establecer una relación en cascada sin ningún problema entre clientes y facturas, es decir: si borro un cliente se borran todas las facturas del mismo (¿para qué quiero facturas que no sé de quién son?)
Sin embargo entre la tabla de facturas y materiales establezco una relación con las características ON UPDATE CASCADE ON DELETE RESTRICT es decir si modifico el código de material se modifica en todas las facturas, pero si intento borrar el código de material y existen facturas con ese código, el borrado no se permite (RESTRICT es el comportamiento por defecto en MySQL).

Todo esto te ahorra cientos de líneas de código y de dudas respecto a los datos que manejas. Aún recuerdo los dolores de cabeza que me dió el viejo Clipper5 con ficheros de datos .DBF con éste tema... cientos de registros perdidos, sin referencias, etc. etc...

===================
No podemos regresar

Citar:

No estoy de acuerdo. Yo siempre establezco las relaciones en cascada cuando deben ser establecidas.
Por ejemplo, si tienes la tablas de Clientes, Facturas y Materiales, puedes establecer una relación en cascada sin ningún problema entre clientes y facturas, es decir: si borro un cliente se borran todas las facturas del mismo (¿para qué quiero facturas que no sé de quién son?)

No estoy de acuerdo (en la relación clientes facturas) , por ejemplo tienes eliminación en cascada de las facturas de un cliente, si por un error ejecutas un delete from clientes where id = 10 eliminarías automáticamente todas las facturas del cliente 10 sin posibilidad de recuperación.
Yo particularmente tengo esta relación en la tabla facturas.
CONSTRAINT rela_factclidat_clientes FOREIGN KEY (id_cliente)
      REFERENCES clientes (id) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE RESTRICT,

me actualiza en cascada el cliente (si cambio el id de un cliente todas las facturas de ese cliente reflejan el cambio) ON UPDATE CASCADE
y me impide eliminar un cliente que tenga alguna factura asociada ON DELETE RESTRICT.

Para eliminar un cliente primero tengo que borrar todas las facturas asociadas a ese cliente.

Una factura es un documento oficial, una vez emitida no puede ser borrada, se compensa mediante un abono.

Esta es mi opinión y las regla de mi sistema de facturación (puedo estar equivocado pero poner ON DELETE RESTRICT me da una gran tranquilidad).

Un saludo
Angel

Bueno... es cuestión de fiarse del mecanismo de borrado. El único que maneja la base de datos "a pelo" soy yo, y ya me guardaré muy bien de hacer ese delete from... que mencionas. Los clientes pueden ser eliminados por mis usuarios, pero no sin pasar una serie muy amenazadora de avisos. Si aún así lo elimnan... allá ellos.
Es cuestión de estilos de programación, supongo.

===================
No podemos regresar

Concuerdo con angelnu. Lo de borrar en cascada no es que no se pueda usar. Es que hay que pensarlo tres veces antes de ponerlo.

Por ejemplo en el caso de las facturas la regla de que no puede haber facturas sin cliente es una regla de hierro de manera que poner integridad referencial en ese caso es correcta; sin embargo también es cierto que las facturas no se borran nunca por lo que no debe haber posibilidad de borrarlas y por tanto un delete where cliente=10 borraría las facturas del cliente 10. Eso es objetivamente equivocado.

Por esa razón en ese caso debería haber integridad referencial pero no debería haber delete en cascada

 

Por otra parte ya que estamos en esto explico también las distintas clases de relaciones

relación uno a varios
Es la mas común. Es aquella en la que a cada registro de la tabla A le pueden corresponder muchos (o ninguno) de la tabla B.
Este es el caso de la relación clientes facturas. A un cliente le pueden corresponder muchas o ninguna factura pero a cada factura solo le puede corresponder un cliente.

Relación uno a uno
Es cuando a cada registro de la tabla A le puede corresponder un solo registro de la tabla B y viceversa.
Es el caso de una tabla de clientes y otra de historial médico. Cada cliente puede tener un historial médico (o ninguno) pero no mas. Tampoco un historial médico puede pertenecer a mas de un cliente.

Relación muchos a muchos
Es cuando a cada registro de la tabla A le pueden corresponder muchos registros de la tabla B y a cada registro de la tabla B le pueden corresponder muchos registros de la tabla A.
Es el caso de una relacilón de recetas e ingredientes. Una receta puede tener muchos ingredientes, pero cada ingrediente puede estar presente en muchas recetas.

Cuando esto ocurre SIEMPRE se resuelve con una TERCERA TABLA C que contiene al menos los códigos de la tabla A y B y tiene una relación uno a muchos A->C y B->C

Un saludo

Eso de impedirle al cliente (tu cliente) que pueda elimnar "sus" facturas puede ser problemático, igual que puede serlo impedir que modifiquen su registro de entradas y salidas de documentos (que se supone que es inamovible), el registro de horario de personal, etc. etc.

¿No habéis oído hablar de la contabilidad "B"? ¿de los registros reciclados? ¿de los jefes que llegan a su hora incluso cuando no vienen?

Como informático creo que me toca el papel de asegurarme que en la base de datos hay lo que el que paga quiere que haya y que se pueda hacer lo que el que paga quiere que se haga. Ni más, ni menos. Si el menda se mete en camisas de once varas con hacienda o con quien sea... ese es su problema.

Repito que es cuestión de estilos.

Saludos

===================
No podemos regresar