Hola SidP,
Lógicamente hay muchas cosas que por razones de rendimiento es mejor que hagan los SGBD, como por ejemplo encargarse de la consistencia de los datos mediante claves foráneas. No es que tenga pruebas o estudios que lo prueben, pero parece lógico. Además es más seguro que ocuparse uno mismo
El problema, según lo veo, tiene 2 raíces:
En principio, la falta de soporte por parte de MySQL. Hasta hace algunos años, las tablas por defecto de MySQL (MyISAM) no soportaban transacciones (creo que ahora tampoco, que hay que usar tablas InnoDB), además el soporte de procedimientos almacenados es reciente (MySQL 5).
Al ser el motor más usado, esto implica malas costumbres.
Por otro lado está el tema de la falta de profesionalidad. Pocas personas aprenden a usar transacciones, procedimientos y claves foráneas, principalmente porque la formación en este sentido es deficiente (los cursos de "programador web" que conozco dan vergüenza), y a veces también porque un día comenzaron a programar, les salió bien, lo siguieron haciendo y nunca buscaron información sobre este tema.
Claro, después les va lenta una aplicación que hace un SELECT * en una tabla de millones de registros, y no saben cuál es el problema...
Las bondades de los SGBD son en su mayoría compartidas por todos ellos. No creo que usarlas repercuta de forma negativa en la reutilización de código, y estoy seguro de que aportan seguridad sin reducir la velocidad de la aplicación.
En las estructuras de las tablas es otro tema, ya que obviamente no es lo mismo tener 10 tablas sin vincular y querer cambiar la estructura, que tener las mismas 10 tablas con claves entre sí. Será más complicado, pero hay que tener en cuenta que no es una tarea que se haga muy seguido, considerando que antes de empezar un proyecto complejo debería existir una fase de diseño, en la que se debería estudiar la estructura de base de datos a usar.
Saludos.
