Barrapunto

Uf, menudo "pepino" me ha salido, pero qué bien me ha venido repasar SQL, que lo tenía oxidado y lo voy a necesitar en breve :)

Académica explicación, sí señor.

Nada que añadir, excepto si cabe, una aclaración para los menos "avanzados":

"Por mantener la integridad referencial entiendo que es mantener la correspondencia de las claves ajenas entre las tablas.", significa que la cualquier acción sobre el campo id_cliente de la tabla clientes o bien se propagará a las tablas relacionadas (dni_clientes) o simplemente el gestor de bases de datos la capará (impedirá que se realice).

En la práctica, la sentencia

delete from clientes where id_cliente = 3

Dará un error si en la tabla dni_clientes existe un registro con id_cliente=3

En el caso de un update, (cosa rara hacer un update de un identificador de registro, pero sirve para el ejemplo) en la mayoría de casos también daría un error, pero en otros casos se puede propagar el cambio (cambiar el id_cliente de todos los registros de dni_clientes que se correspondan con el cliente actualizado)

Espero no haber liado más las cosas ;-)

Hasta ahora las foreign keys solo las usaba en CREATE, a no ser que usaras InnoDB, ( yo siempre he usado MYiSAM, por el tipo de aplicaciones que suelo hacer. De todas maneras por lo que he visto, tampoco son funcionalidades que añadan algo muy diferente. Por lo que he visto, no hay nada que ahora se pudiera hacer y antes no, quizá ahora más cómodamente. Lo que si me ha sorprendido ha sido leer por ahi en un sitio de SQL server que es mejor no usar cursores [sql-server...rmance.com], que son muy ineficientes.

Sin "stored procedures" creo que también podía vivir, será algo más eficiente tenerlas en el servidor, pero tampoco añaden funcionalidad que no puedas poner tú en tu código.

Realmente, ¿Qué tienen otras bd afamadas como más potentes como Oracle, que no puedas hacer con mysql o Posgres?