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?

Solo un par de comentarios minimos:

>Vistas: Se usan para consultas complejas, y son
>como una forma de encapsular consultas. Ejemplo:
>
> create view mi_vista as
> select nombre,dni from clientes, dni_clientes
> where >clientes.id_cliente=dni_clientes.id_cliente

>Podríamos hacer una consulta sobre esa vista,
>como si se tratase de una tabla. Ejemplo:
>
> select nombre,dni from mi_vista where
> nombre="pepe";
>
>En este caso no sería muy útil ya que podríamos >haber obtenido los mismos resultados sin recurrir >a una vista, pero es sólo un ejemplo :)

Una utilidad de las vistas es limitar el acceso a datos segun usuarios, por ejemplo, en la vista solo puedes ver el nombre y el dni, no el resto de los datos.

>Procedimientos almacenados: son procedimientos
>escritos en un lenguaje determinado que se
>almacenan en la base de datos. En Oracle el
>lenguaje es PL/SQL, en PostgreSQL es PLPG/SQL.
>Ejemplo de una función en PLPG/SQL:

Con lo que puedes poner muchisimo codigo de validaciones, calculos y demas dentro de la base de datos (ojo, eso significa que para cambiar de base de datos despues tienes que re-escribir todo ese codigo), con lo que se puede acelerar mucho el acceso.

Tambien usando triggers (?disparadores?) puedes llamar esos procedimientos almacenados al acceder a los datos (por ejemplo, cuando creas un nuevo cliente, puedes crear una nueva entrada en una tabla llamada "cuenta" usando algunos de los datos que te han entrado en cliente).

Muy buena explicacion, por cierto.