Barrapunto

Estoy de acuerdo contigo. No es un maestro.

El problema N2 y hablando sólo de diseñar la interfaz se debe a que las aplicaciones de ejecución local están preparadas para correr en una máquina con un bus de datos muy veloz y aunque el programa diseñador de la interfaz genere código extra porque el diseñador humano ha pulsado varias veces el botón que no debía, la pérdida de rendimiento por ejecutar cosas inútiles no se nota demasiado al ejecutar la aplicación.

En cambio en aplicaciones web el "bus de datos" es la línea telefónica que es bastante limitada en velocidad y la carga de la página tarda lo suyo si el código de la interfaz no está optimizado y hay marcas redundantes (La nueva web del congreso es, o era, un buen ejemplo).

Ahora que cada vez tenemos más ancho de banda se puede empezar a desoptimizar la generación del código web con programas que automaticen y reduzcan la tarea de creación de la interfaz si esto mejora su velocidad de desarrollo y por ende el precio de las aplicaciones aunque en mi opinión por donde habría que tirar para aplicaciones remotas es en protocolos tipo X que permitan enviar al cliente sólo las partes de la interfaz que cambien y dejar el HTML sólo para documentos de hipertexto. Pero claro, con la de recursos invertidos en tecnología web no veo claro que alguien saque un protocolo nuevo y el mundo se vuelque en él. Igual con las iniciativas de Adobe y Microsoft sobre interfaces ricas a través de http veamos un cambio o quizás salga un churro peor que lo que hay ahora.

Sobre el problema 5 acerca de la integridad referencial, no en todos los casos tendrían las mismas restricciones que un borrado físico. Te pongo un ejemplo:

Una BD en la que se almacenan en las tablas los usuarios que modifican cada uno de los registros. Si en algún momento un usuario causa baja, utilizando un borrado lógico se seguiría manteniendo la integridad.

¿Pero este tío no ha oido hablar del delete on cascade? Problema 11, la falta de cultura.