Ejercicios y práctica · Acceso a Datos · DAM

Qué deberías ser capaz de hacer

Errores frecuentes que la práctica debería detectar

• Confundir una clase con un componente: Una clase es una plantilla para objetos, mientras que un componente es una unidad de software autocontenida y desplegable que puede estar compuesta por varias clases. Corrección: Un componente debe tener una interfaz bien definida, ser autocontenido y reutilizable en diferentes contextos, no solo una clase aislada.
• Ignorar la gestión de dependencias: No usar un gestor de dependencias puede llevar a conflictos de versiones (DLL Hell en .NET, Jar Hell en Java) o a la falta de librerías necesarias. Corrección: Integrar Maven, Gradle o NuGet desde el inicio del proyecto para declarar y resolver dependencias de forma automática y consistente.
• No cerrar recursos (ficheros, conexiones DB): Esto puede llevar a fugas de memoria, bloqueos de ficheros o agotamiento de conexiones a la base de datos. Corrección: Utilizar bloques `try-with-resources` en Java o sentencias `using` en C# para asegurar el cierre automático de los recursos, o cerrar explícitamente en bloques `finally`.
• Inyección SQL: Construir consultas SQL concatenando cadenas directamente con la entrada del usuario. Corrección: Usar `PreparedStatement` en JDBC o `SqlCommand` con parámetros en ADO.NET para evitar la inyección SQL, ya que los parámetros se envían por separado de la consulta.
• Problemas de rendimiento con ORM (N+1 selects, carga perezosa mal gestionada): un uso ingenuo del ORM puede generar muchas consultas pequeñas en vez de una consulta optimizada. Corrección: entender cómo el ORM traduce las operaciones a SQL, elegir estrategias de carga adecuadas (eager/lazy) según el caso y recurrir a consultas nativas o proyecciones (DTOs) cuando el mapeo automático no sea eficiente.
• Ignorar el esquema en bases de datos XML: aunque son flexibles, no definir una estructura esperada para los documentos puede provocar inconsistencias difíciles de consultar. Corrección: usar XML Schema (XSD) o DTD para validar los documentos antes de insertarlos, facilitando consultas XQuery consistentes.
• Confundir 'no necesito SQL' con 'no necesito entender el modelo de datos': usar un ORM no exime de diseñar bien las entidades y sus relaciones; un mal diseño de entidades genera consultas ineficientes independientemente de la herramienta usada.
• Falta de cobertura de pruebas: No probar todos los escenarios (casos límite, errores) del componente de acceso a datos. Corrección: Diseñar pruebas que cubran el 100% de las ramas de código importantes, incluyendo escenarios de éxito, error, datos nulos y volúmenes grandes.
• Documentación desactualizada o inexistente: Un componente sin documentación es difícil de usar y mantener. Corrección: Integrar la generación de documentación en el proceso de desarrollo (ej. Javadoc, XML Comments) y mantenerla actualizada con cada cambio significativo en el API del componente.
• Confundir NXDB con bases de datos que simplemente almacenan XML como CLOB/BLOB: La NXDB entiende y procesa la estructura XML internamente, no solo la guarda como un texto. Esto afecta la eficiencia de las consultas. Corrección: Entender que la 'nativa' implica indexación y consulta directa de la estructura.
• Aplicar NXDB a datos puramente relacionales: Intentar modelar datos tabulares simples en XML puede introducir complejidad innecesaria y penalizar el rendimiento. Corrección: Evaluar la naturaleza de los datos y si su estructura jerárquica es intrínseca o artificial.
• Subestimar la curva de aprendizaje de XQuery/XPath: Asumir que son triviales para un desarrollador SQL puede llevar a retrasos. Corrección: Planificar tiempo para la formación y práctica en estos lenguajes de consulta.
• Dejar la contraseña por defecto del usuario 'admin': riesgo de seguridad grave. Corrección: cambiarla inmediatamente tras la instalación, desde la GUI o mediante comandos administrativos verificados en la documentación oficial de la versión usada.
• Suponer que un fallo de conexión cliente-servidor es un problema del código de la aplicación sin comprobar antes puertos y firewall. Corrección: verificar con herramientas de red que los puertos configurados (1984/8984 por defecto) están abiertos y accesibles.
• Buscar un archivo 'basex.properties' que no existe en BaseX. Corrección: la configuración persistente se gestiona mediante el archivo oculto '.basex' y comandos internos (SET), cuyo nombre y ubicación exactos conviene confirmar en la documentación oficial de la versión instalada.
• Usar comandos inexistentes como 'CREATE FOLDER' o 'DROP FOLDER': BaseX no los reconoce y la aplicación lanzará una excepción. Corrección: usar los comandos reales 'CREATE DB', 'ADD', 'DELETE' y 'DROP DB' según se quiera crear una base de datos, añadir un documento en una ruta, borrar una ruta o eliminar la base de datos completa.
• Confundir el modelo de colecciones de BaseX con el de otros gestores (por ejemplo eXist-db): asumir que existen colecciones independientes de la base de datos lleva a diseñar operaciones que no existen en la API. Corrección: comprobar en la documentación oficial del gestor instalado cómo se modela ese concepto antes de programar.
• No abrir la base de datos correcta antes de operar: ejecutar 'ADD' o 'DELETE' sin haber hecho antes 'OPEN nombre_bd' provoca un error o afecta a la base de datos equivocada. Corrección: comprobar con 'LIST' que la base existe y ejecutar 'OPEN' antes de cualquier operación sobre documentos.