Ejercicios y práctica · Programación · DAM

Qué deberías ser capaz de hacer

Errores frecuentes que la práctica debería detectar

• Confundir SQL con un SGBDR: SQL es el lenguaje para interactuar con la base de datos, mientras que el SGBDR es el software que gestiona la base de datos. Causa: Falta de distinción conceptual. Corrección: Entender que SQL es una herramienta que el SGBDR interpreta y ejecuta.
• No entender la necesidad de un driver: Intentar conectar sin el driver adecuado o con una versión incompatible. Causa: Desconocimiento del papel del driver como puente de comunicación. Corrección: Investigar y descargar el driver específico para la versión del SGBDR y del lenguaje de programación utilizado.
• No cerrar recursos (conexiones, statements, resultsets): Causa: Olvido o manejo incorrecto de excepciones. Consecuencia: Agotamiento de recursos del servidor de base de datos y de la aplicación, llevando a fallos. Corrección: Implementar el patrón `try-with-resources` o asegurar el cierre explícito en bloques `finally`.
• Vulnerabilidad de Inyección SQL: Causa: Construir sentencias SQL concatenando directamente entradas de usuario sin sanitización. Consecuencia: Un atacante puede manipular la consulta para acceder, modificar o borrar datos no autorizados. Corrección: Utilizar siempre `PreparedStatement` con parámetros para todas las entradas de usuario, nunca concatenar directamente.
• No usar transacciones para operaciones complejas: Causa: Desconocimiento de la importancia de la atomicidad. Consecuencia: La base de datos puede quedar en un estado inconsistente si una parte de una operación multi-paso falla. Corrección: Identificar secuencias de operaciones que deben ser atómicas y envolverlas en transacciones con `commit` y `rollback`.
• Validación de datos solo en la UI: Causa: Confiar únicamente en la validación del lado del cliente. Consecuencia: Datos inválidos pueden ser insertados si se bypassa la UI o si la validación es insuficiente. Corrección: Implementar validación de datos tanto en la UI como en la capa de servicios/negocio y, como última línea de defensa, en el esquema de la base de datos.
• Confundir una BDOO con una base relacional que usa ORM, atribuyendo a una lo que corresponde a la otra
• Subestimar la dificultad de evolucionar el esquema de clases cuando ya existen objetos persistidos con una versión anterior
• Confundir identidad de objeto con igualdad de valores, provocando errores al comparar o actualizar objetos recuperados
• Problemas de compatibilidad de versiones
• Errores de configuración de rutas o variables de entorno
• Falta de permisos para la instalación o ejecución
• Errores en la gestión de transacciones
• Problemas de concurrencia al actualizar objetos
• Consultas ineficientes o incorrectas
• No cerrar correctamente las conexiones a la BDOO
• Confundir herencia con composición: Un error común es usar herencia cuando una clase 'tiene un' objeto de otra clase, en lugar de 'ser un' tipo de esa clase. Por ejemplo, un 'Coche' tiene un 'Motor', no 'es un' 'Motor'. Corrección: Utilizar composición (un atributo de tipo Motor en la clase Coche) en lugar de herencia.
• Jerarquías de herencia demasiado profundas: Crear cadenas de herencia muy largas puede hacer el código difícil de entender y mantener, ya que el comportamiento de una subclase puede depender de muchas superclases. Corrección: Limitar la profundidad de las jerarquías y refactorizar para usar interfaces o composición cuando sea más apropiado.