Clase Teórica 1

Introducción a la Materia

Objetivos del Curso

• Bienvenida a los participantes y breve introducción sobre el curso, destacando que se enfocará en la práctica y experiencia más que en teoría.

• El objetivo principal es formar un criterio que permita abordar problemas relacionados con el almacenamiento de información, no solo adquirir conocimientos técnicos específicos.

Metodología de Enseñanza

• Se comenzará con conocimientos previos y se añadirán nuevos conceptos, como bases de datos y nociones básicas de arquitectura de software.

• La enseñanza incluirá experiencias reales del instructor, quien ha trabajado en proyectos industriales durante 25 años.

Estructura del Curso

Interacción y Dinámica

• Se fomentará la interacción entre estudiantes e instructores; se anima a hacer preguntas durante las clases.

• Las clases serán sincrónicas todos los jueves a las 9 de la mañana, permitiendo el intercambio de opiniones y anécdotas.

Evaluación Práctica

• La evaluación no será teórica; consistirá en una serie encadenada de trabajos prácticos para aplicar lo aprendido.

• Se utilizará Java como plataforma para las prácticas debido a su familiaridad general entre los estudiantes.

Prácticas Específicas

Primeras Prácticas

• La primera práctica consistirá en guardar información en una base de datos utilizando un mapeador.

• En la segunda práctica, se levantará información desde la base de datos para realizar consultas simples hasta complejas.

Uso de Bases No SQL

• La última práctica abordará bases de datos NoSQL, específicamente por su simplicidad y potencia.

• Los estudiantes aprenderán a trabajar con comandos básicos en consola, enfatizando que este uso no es común en situaciones profesionales típicas.

Arquitectura de Aplicaciones y Evaluación

Diseño de la Aplicación

• Se discute la arquitectura necesaria para una aplicación que pueda escalar con el tiempo, integrando mapeo y objetos de manera eficiente.

• La importancia de reutilizar soluciones existentes en lugar de crear nuevas desde cero es enfatizada para optimizar el desarrollo.

Proceso de Evaluación

• Para aprobar la cursada, los estudiantes deben completar prácticas que tienen un seguimiento y entrega específica.

• El examen final tiene dos modalidades: una tradicional con preguntas teóricas y prácticas, enfocándose en la comprensión más que en la memorización.

Modalidades del Examen Final

• Se menciona que las evaluaciones orales se realizarán a través de plataformas como Meet o Zoom debido a las restricciones actuales por pandemia.

• Alternativamente, los estudiantes pueden optar por continuar trabajando en proyectos prácticos o desarrollar nuevos trabajos utilizando herramientas aprendidas.

Temas Adicionales

• Se introduce el concepto de Big Data como un tema relevante, aunque no se profundiza en su teoría ni práctica durante el curso.

• Se anima a los estudiantes a integrar contenidos de esta materia con otros trabajos académicos, lo cual podría ser útil para sus tesis futuras.

Organización del Curso

• Las clases se llevarán a cabo todos los jueves a las 9 AM, con grabaciones disponibles para aquellos que no puedan asistir.

• Se establece un ambiente abierto para preguntas y aclaraciones durante las sesiones, fomentando la participación activa.

Conocimientos Previos Requeridos

• Se verifica si los estudiantes tienen conocimientos previos sobre Java y patrones de diseño antes de avanzar con el contenido del curso.

¿Qué es un patrón de diseño?

Introducción a los patrones de diseño

• Se enfatiza la importancia de entender qué es un patrón de diseño, ya que se aplicará a lo largo del curso.

• Se invita a los participantes a detenerse y repetir cualquier concepto que no comprendan, resaltando que nadie nace sabiendo todo.

Paradigmas en el desarrollo

• Se menciona la necesidad de analizar diferentes paradigmas al momento de desarrollar software.

• Los desarrolladores enfrentan el dilema sobre qué herramientas utilizar para sus proyectos, destacando la importancia de elegir adecuadamente.

Elección del paradigma adecuado

• La elección del paradigma debe ser reflexiva; no se debe optar por una herramienta solo porque está disponible.

• Es probable que los desarrolladores opten por programación orientada a objetos debido a su formación académica.

Desafíos en el uso de bases de datos

Uso de motores relacionales

• Almacenar información es crucial; se espera que los desarrolladores utilicen motores relacionales por experiencia y disponibilidad.

• Muchos recién graduados cometen errores al cambiar tecnologías sin considerar las aplicaciones existentes y sus prácticas.

Interacción con sistemas existentes

• El desarrollo no ocurre en un vacío; es raro que un sistema opere sin interactuar con otros sistemas.

• La falta de comprensión sobre cómo conviven múltiples sistemas puede llevar a decisiones erróneas en el desarrollo.

Ecosistemas tecnológicos y su complejidad

Realidades del entorno tecnológico

• Ejemplos como Arba utilizando mainframe muestran la resistencia al cambio en algunos ecosistemas tecnológicos.

• La migración lenta hacia nuevas tecnologías resalta la dificultad para implementar cambios significativos en entornos establecidos.

¿Cuáles son los mitos sobre las bases de datos relacionales?

Mitos y realidades sobre las bases de datos

• Se menciona que existe un mito acerca de la cantidad de alternativas en bases de datos relacionales, sugiriendo que no son tantas como se piensa.

• Al realizar un ejercicio en aula para contar nombres de bases de datos relacionales conocidas, se concluye que hay pocas opciones realmente utilizadas.

• La concentración del mercado es evidente; por ejemplo, Oracle adquirió MySQL, lo que ha llevado a una unificación en el uso de herramientas.

Estándares y su importancia

• Se introduce el estándar SQL 92, que facilita la migración entre diferentes motores de base de datos si se sigue este estándar.

• La adherencia al SQL 92 puede reducir costos al cambiar motores debido a licencias o necesidades específicas.

¿Qué desafíos enfrentan los sistemas de recursos humanos?

Implementación y costos

• Se presenta un caso anecdótico sobre un sistema nacional de recursos humanos desarrollado por un organismo estatal.

• El organismo decidió compartir su sistema con otros, pero esto generó resistencia entre los demás organismos.

Resultados inesperados

• A pesar del esfuerzo por implementar el sistema compartido, solo alrededor del 10% logró hacerlo debido a altos costos asociados con las licencias.

• Los costos anuales para mantener la licencia eran mayores que el presupuesto total destinado a gestionar recursos humanos.

¿Por qué es difícil cambiar motores de base de datos?

Limitaciones técnicas

• Aunque se podría pensar en cambiar a otro motor como PostgreSQL o MySQL usando SQL 92, existen complicaciones técnicas significativas.

• El código fuente está tan integrado con Oracle que el esfuerzo para migrar es mayor que desarrollar una nueva aplicación desde cero.

Reflexiones finales

• Las anécdotas ilustran cómo decisiones no consideradas pueden afectar drásticamente el éxito o fracaso en proyectos tecnológicos.

• Es importante reconocer situaciones absurdas en la gestión técnica para evitar errores similares en futuras implementaciones.

¿Cómo trabajar con objetos y bases de datos?

Introducción a la relación entre objetos y bases de datos

• Se plantea la importancia de que los estudiantes reconsideren el uso de objetos en programación, especialmente en contextos donde su aplicación es necesaria.

• Se menciona que en la primera materia sobre objetos, los estudiantes no tenían claridad sobre el origen de estos, lo cual es fundamental para entender su integración con bases de datos.

Desafíos del manejo de objetos

• Se discute un problema clave: al trabajar con bases de datos, se deben considerar las transacciones abiertas y cómo afectan a los objetos en memoria.

• La complejidad aumenta cuando se modifican objetos en memoria que representan registros en una base de datos compartida.

Objetivos del aprendizaje práctico

• El objetivo es utilizar técnicas avanzadas para mapear modelos de objetos a estructuras relacionales sin perder eficiencia.

• Se enfatiza que la experiencia del usuario es prioritaria; el rendimiento debe ser óptimo independientemente del diseño técnico detrás.

Mapeo entre paradigmas

• Se introduce el concepto de mapeo entre el modelo orientado a objetos y las bases de datos relacionales, destacando la necesidad de traducir estructuras adecuadamente.

• Es crucial poder "hidratar" los modelos objeto desde estructuras relacionales para mantener integridad y funcionalidad.

Herramientas y prácticas recomendadas

• La práctica inicial se centrará en usar un mapeador específico (Hibernate), aunque no será una clase magistral sobre este tema.

• Los estudiantes aprenderán a manejar información utilizando tanto conceptos teóricos como prácticos relacionados con Hibernate y JPA.

Consideraciones sobre entidades y relaciones

• Al mezclar paradigmas orientados a objetos con bases relacionales, surgen consideraciones importantes que deben tenerse en cuenta para evitar problemas comunes.

• La simplicidad del modelo entidad-relación permite explicar fácilmente sus componentes básicos incluso a personas sin conocimientos profundos en informática.

¿Cómo modelar datos de manera efectiva?

Introducción a la modelación de datos

• Se introduce el concepto de "cajitas" para representar conjuntos de datos, donde los "rulitos" indican que se está almacenando información específica, como el DNI de una persona.

• En reuniones de especificación, es crucial entender el dominio del usuario y sus necesidades, ya que pueden no conocer todas las posibilidades técnicas disponibles.

Complejidades en la modelación

• La relación entre genes y cromosomas se utiliza como ejemplo para ilustrar cómo un modelo simple puede ser inadecuado; muchos genes pueden estar relacionados con varios cromosomas.

• Modelar estructuras complejas como grafos en bases de datos relacionales puede resultar costoso y complicado debido a la necesidad de realizar consultas recursivas.

Generalización y especialización en diseño

• Se discute la importancia de generalizar o especializar modelos al diseñar bases de datos, utilizando "cajitas" para representar relaciones comunes y específicas.

• En programación orientada a objetos, la herencia permite que las subclases hereden atributos automáticamente, mientras que en bases de datos relacionales esto debe hacerse manualmente.

Desafíos en bases de datos relacionales

• Al hacer generalizaciones en diseño relacional, cada entidad hija requiere un join para acceder a los atributos comunes, lo cual puede afectar negativamente el rendimiento.

• La falta de representación directa entre tablas hijas y padres complica la gestión y actualización del modelo cuando se agregan nuevos atributos.

Conclusiones sobre modelación eficiente

• La documentación es esencial pero frecuentemente desactualizada; por lo tanto, es vital tener claridad sobre las jerarquías entre tablas al trabajar con grandes volúmenes (3000 - 4000 tablas).

• El desafío radica en mantener una estructura clara y accesible dentro del modelo relacional para facilitar futuras modificaciones.

¿Cómo afecta la normalización en el diseño de bases de datos?

Complejidades en la Normalización

• La normalización puede ser complicada debido a la inclusión de nombres inusuales en las tablas, lo que dificulta determinar si un atributo es correcto.

• Se plantea una reflexión sobre la experiencia laboral y el uso práctico del álgebra o cálculo de tuplas, sugiriendo que muchos no aplican estos conceptos en su trabajo diario.

• Se menciona que aunque hay una base matemática para validar consultas, muchas veces los profesionales se basan más en la observación directa de los datos.

• La crítica no es hacia el contenido teórico, sino hacia la falta de aplicación práctica del conocimiento matemático al escribir consultas.

• Se observa que muchos desarrolladores realizan consultas sin un entendimiento profundo, lo que puede llevar a errores al interpretar los resultados.

Desafíos y Prácticas Comunes

• A menudo se realizan desarrollos donde se verifica manualmente si las consultas devuelven resultados correctos, evidenciando una falta de confianza en el diseño inicial.

• La normalización es fundamental para evitar repetir información; sin embargo, algunos optan por soluciones prácticas como almacenar colecciones dentro de columnas.

• Los principios de normalización surgieron cuando el costo del almacenamiento era alto; hoy día este enfoque puede no ser tan relevante debido a cambios tecnológicos.

• El costo actual del almacenamiento permite cuestionar algunas ideas tradicionales sobre el diseño eficiente de bases de datos.

• Un ejemplo práctico muestra cómo un sistema desnormalizado puede ofrecer tiempos de respuesta mucho más rápidos comparado con uno completamente normalizado.

Nuevas Perspectivas sobre Microservicios

• En el contexto actual, especialmente con microservicios, cada componente tiene su propia base de datos, lo cual cambia las reglas del diseño tradicional.

• Este enfoque implica considerar cómo se conectan diferentes partes del sistema y cómo esto afecta al mapeo y selección de herramientas adecuadas para el desarrollo.

Patrones y Buenas Prácticas

• Se introduce el patrón "root object", que sugiere tener objetos principales que faciliten el acceso a otros objetos dentro del modelo diseñado.

• Este patrón busca resolver problemas comunes relacionados con la conexión entre diferentes tipos o clases dentro del sistema.

• Al modelar entidades complejas como bancos, es crucial identificar primero las entidades principales antes de definir otras clases relacionadas.

¿Cómo modelar un sistema bancario?

Introducción al patrón root object

• El patrón root object sugiere que al modelar un objeto, se debe representar el sistema en sí. Esto ayuda a definir los límites del sistema y ubicar la lógica correspondiente.

Lógica de negocio en el modelo

• Al modelar un banco, la lógica que impide tener dos clientes con el mismo DNI debería estar en el banco, no en cada cliente. Esto permite una búsqueda eficiente dentro de la colección de usuarios.

Diferencias entre modelos orientados a objetos y relacionales

• En un diseño relacional, no se debe pensar en una entidad o tabla llamada "banco". En cambio, las tablas y sus relaciones representan al banco como un todo.

Complejidad del modelo relacional

• La simplicidad del modelo relacional puede ser engañosa; es importante entender que representa un sistema multibancario donde diferentes bancos interactúan.

Ejercicio práctico: Modelando un recibo de sueldo

• Se plantea el ejercicio de modelar un recibo de sueldo utilizando entidades y relaciones. Este ejercicio revela la complejidad inherente a los sistemas simples como el modelo relacional.

Identificación de entidades en un recibo de sueldo

Análisis del recibo

• Se presenta un ejemplo real (aunque simplificado) de un recibo emitido por la FIP para empleados públicos, destacando su formato PDF.

Detección de entidades necesarias

• Se pregunta cuántas entidades se pueden identificar al modelar este recibo. Por ejemplo, se menciona que datos como domicilio o antigüedad no son adecuados para tablas de dominio.

Tablas adicionales requeridas

• Es necesario crear tablas adicionales para categorías y tipos relacionados con liquidaciones, lo cual complica aún más el modelo.

Detalles sobre liquidaciones

• Las liquidaciones pueden incluir diferentes tipos (retroactivo, viáticos), lo que requiere más tablas para gestionar esta información adecuadamente.

Consulta SQL para obtener datos del PDF

• Se anticipa mostrar la consulta SQL necesaria para extraer los datos asociados al PDF del recibo mencionado anteriormente.

¿Cómo optimizar consultas en bases de datos?

Análisis de la complejidad del código

• Se menciona que el código es difícil de entender debido a su longitud y complejidad, lo que plantea dudas sobre su eficiencia al consultar múltiples tablas.

• El presentador utiliza un formateador de código para mejorar la legibilidad, mostrando que el código tiene 142 líneas y contiene múltiples elementos complejos.

• Se destaca la cantidad de tablas involucradas en una consulta y la necesidad de realizar subconsultas, lo cual incrementa la carga al obtener un PDF.

Desafíos en sistemas con gran volumen de datos

• Se menciona que hay organismos con hasta 600,000 empleados, lo que complica aún más el diseño del sistema y las consultas necesarias para procesar información.

• La idea de "quitarse la mochila" se refiere a simplificar el proceso eliminando cálculos innecesarios al almacenar datos ya preparados.

Ventajas del almacenamiento eficiente

• Almacenar información en formato JSON permite recuperar metadatos asociados junto con los PDFs solicitados sin complicaciones adicionales.

• Comparar modelos relacionales versus no relacionales muestra que los primeros pueden ser costosos por su naturaleza estructurada y dificultad para indizar ciertos tipos de datos.

Estrategias para mejorar la persistencia

• La propuesta es almacenar recibos completos como unidades mínimas, evitando costos adicionales relacionados con subconsultas o joins.

• Se enfatiza la importancia de adaptar el sistema a las necesidades específicas del usuario final sin depender excesivamente del ID o estructura interna.

Impacto del diseño en metodologías ágiles

• Se plantea si adoptar metodologías ágiles mejora realmente la calidad del código o si esta última determina cuán ágilmente se pueden implementar cambios.

• Un cambio significativo como cambiar el motor de base de datos puede ser problemático si el sistema está rígidamente acoplado a SQL.

¿Cómo afecta la elección de base de datos a las aplicaciones?

Elección de bases de datos y su impacto

• Se discute la elección entre diferentes sistemas de gestión de bases de datos (Oracle, SQL Server, NoSQL), destacando que todos funcionan en ciertos contextos.

• Se menciona el concepto de "aplicaciones de 12 factores", donde se propone que una aplicación debe ser independiente del tipo de base de datos utilizada, limitándose a cambiar solo la configuración al realizar un cambio.

Problemas con SQL embebido

• Se plantea la pregunta sobre los problemas potenciales al tener SQL embebido en el código. Se sugieren varios problemas, como errores en tiempo de ejecución debido a consultas mal escritas.

• Un ejemplo es que el código Java puede no detectar errores hasta que se ejecute en producción, lo cual puede llevar a fallos si hay errores sintácticos o semánticos.

Estándares y compatibilidad entre bases

• El estándar SQL 92 no es realmente uniforme; diferentes motores pueden interpretar comandos SQL (como terminaciones) de manera distinta.

• La nomenclatura también presenta problemas: por ejemplo, "user" es una palabra reservada en Oracle pero no en otros sistemas como MySQL.

Desafíos en mantenimiento y cambios

• Se comparte una experiencia personal sobre mantener una aplicación sin acceso al código fuente original, lo que resalta la importancia del control del código.

• La discusión incluye si es beneficioso tener metadatos dentro del código para mapear información a tablas específicas.

Cambios en arquitecturas y soluciones

• Se cuestiona con qué frecuencia realmente cambian las bases de datos en entornos reales versus teóricos.

• Al cambiar entre tipos similares (por ejemplo, Oracle a MySQL), se considera cuánto debe adaptarse el código. Esto incluye cambios más profundos si se cambia también la solución ORM utilizada.

Persistencia y lógica empresarial

• La transición hacia soluciones basadas en la nube plantea preguntas sobre cómo debería cambiar el software; idealmente, no debería haber cambios significativos en la lógica empresarial.

• Finalmente, se enfatiza que cada operación crítica (como un insert) implica un acoplamiento con una solución específica, lo cual puede limitar futuras opciones tecnológicas.

¿Cómo evitar dependencias en la persistencia de datos?

Introducción a la Persistencia sin Dependencias

• El orador plantea la necesidad de minimizar las dependencias con el motor y la solución de persistencia, sugiriendo que se debe cuestionar cuántas veces es necesario escribir el comando save en el código para facilitar futuros cambios en la solución de persistencia.

• Se menciona que es posible guardar objetos sin utilizar sentencias explícitas de inserción o guardado, lo cual se considera una ventaja significativa.

Ejemplo Práctico en Eclipse

• El orador presenta un ejemplo práctico utilizando Eclipse, donde crea un objeto teléfono y una colección de teléfonos, así como una persona llamada Elton, sin incluir líneas de código relacionadas con la persistencia hasta ese momento.

• A medida que avanza el código, comienzan a aparecer elementos relacionados con Hibernate como session factory, transaction, y comandos como save y commit, lo que indica dependencia del sistema de base de datos.

Problemas con Código Dependiente

• Se critica el uso del código que está fuertemente acoplado a una base de datos. La presencia constante de transacciones sugiere un diseño poco limpio y problemático.

• Se describe cómo abrir sesiones y realizar transacciones puede complicar el manejo del código. Esto incluye abrir conexiones para consultas SQL directas, lo cual no es ideal.

Ejecución del Código y Errores

• Al ejecutar el código, se espera recuperar todas las personas almacenadas en la base. Sin embargo, surge un error al intentar imprimir los teléfonos asociados a cada persona después de haber realizado operaciones sobre ellos.

• El orador enfatiza la importancia de recordar que "el rojo es malo" en Eclipse cuando hay errores. En este caso específico, se produce un fallo al intentar acceder a los teléfonos tras realizar operaciones previas.

Manejo Transaccional y Validación

• Se explica que después de hacer commit a los objetos almacenados en memoria, estos dejan de ser válidos fuera del contexto transaccional. Es crucial operar dentro del ambiente transaccional para evitar problemas al manipular objetos guardados.

• Para recuperar información correctamente desde la base de datos después del commit, se deben seguir ciertas prácticas adecuadas dentro del entorno transaccional; esto implica tener cuidado al manejar los objetos almacenados.

Persistencia por Alcance en Desarrollo de Software

Introducción a la Persistencia

• Se presenta un proceso donde se utilizan dos máquinas para realizar tareas simultáneamente, destacando la importancia de guardar información antes de cerrar una transacción.

• Se observa que al ejecutar el código, los datos no generan errores y se repiten entradas, lo que indica problemas en la gestión de objetos persistentes.

Problemas con el Código Actual

• El código actual es considerado ineficiente; se requiere imprimir datos antes de cerrar la transacción para evitar pérdidas.

• Se enfatiza que este enfoque es poco elegante y sugiere buscar soluciones más efectivas para manejar la persistencia.

Concepto de Persistencia por Alcance

• La "persistencia por alcance" implica que si un objeto ya existe en la base de datos (instancia A), cualquier objeto nuevo vinculado (objeto B) debe ser guardado automáticamente.

• Este método reduce el número de inserciones necesarias al recuperar objetos existentes y asociarlos con nuevos.

Implementación Práctica

• Se ilustra cómo vincular instancias recuperadas con nuevas instancias dentro del código, mejorando así la eficiencia del manejo de datos.

• Un ejemplo práctico muestra cómo los objetos vinculados pueden ser guardados correctamente utilizando un mapeador como Hibernate.

Ejemplo Real con API REST

• Se introduce una aplicación API REST que gestiona usuarios y teléfonos, mostrando cómo implementar persistencia por alcance en un entorno real.

• Al agregar un teléfono a un usuario existente, se demuestra cómo recuperar y vincular objetos eficientemente sin necesidad de reinsertar datos redundantes.

Resultados y Validaciones

• Se realiza una prueba en vivo para dar alta a un nuevo usuario mediante la API, obteniendo respuestas exitosas (estatus 200).

• Finalmente, se valida que al asignar un teléfono a un usuario recuperado, los cambios son reflejados correctamente en la base de datos.

Persistencia y Diseño de Aplicaciones

Importancia de la Persistencia en el Desarrollo

• Se menciona que un buen diseño de persistencia permite cambiar de base de datos sin necesidad de modificar la aplicación, lo que resalta la importancia de una arquitectura flexible.

• La documentación es clave en el desarrollo; se sugiere que los desarrolladores deben familiarizarse con las buenas prácticas para asegurar un código mantenible.

Identificadores y Soluciones de Persistencia

• Se discute sobre el uso de identificadores únicos (UU y D), que son generados aleatoriamente para evitar repeticiones, lo cual es crucial para mantener la integridad en bases de datos.

• Es importante evaluar cómo se relacionan los objetos con las clases en términos de persistencia. Un mal diseño puede llevar a problemas si se cambia el mapeador utilizado.

Principios SOLID y su Aplicación

• Se introduce el concepto del principio SOLID, que consiste en cinco principios fundamentales para mejorar el diseño y la implementación del software.

• El primer principio, "Single Responsibility", establece que una clase debe tener una única responsabilidad. Esto evita complicaciones al agregar nuevas funcionalidades.

Sustitución y Tipado

• El principio de sustitución Liskov indica que un objeto debe poder ser sustituido por sus subtipos sin alterar las propiedades deseables del programa.

• Se recomienda utilizar tipos más abstractos (como Collection en lugar de ArrayList) para fomentar un código más flexible y menos dependiente de implementaciones específicas.

Acceso Genérico a Bases de Datos

• Se propone usar patrones como "repositorio" para acceder a bases de datos, permitiendo así una interacción genérica independientemente del tipo específico utilizado.

• Este enfoque asegura que cualquier cambio en la base de datos no afecte al código existente, manteniendo así la transparencia y flexibilidad del sistema.

Introducción al Código y Herramientas

Presentación del Código

• Se menciona que el código a presentar no es pseudocódigo, sino código funcional que se utilizará constantemente.

• Se abordarán nociones básicas de mapeo, incluyendo entidades y relaciones utilizando Hbernet y el estándar JPA.

Preparación del Entorno de Desarrollo

• Se ofrece una máquina virtual preconfigurada para evitar inconvenientes en la instalación del motor de base de datos.

• La máquina virtual incluye Java, Eclipse y otros componentes necesarios, facilitando su uso en diferentes sistemas operativos como Ubuntu, Debian, OSX o Windows.

Recomendaciones sobre Instalación

• La máquina virtual está diseñada para Virtual Box y no requiere licencias. Para quienes no puedan usar Virtual Box, se sugiere la instalación local.

• Se recomienda trabajar con un entorno nativo para mejor rendimiento; sin embargo, el uso de la máquina virtual es práctico.

Dudas y Consultas sobre el Curso

Interacción con los Estudiantes

• Se invita a los estudiantes a plantear dudas sobre la cursada o mecanismos finales.

• Se discute la idea de trabajar con APIs para gestionar bases de datos minimizando impactos ante cambios futuros.

Diseño y Estandarización

• El enfoque debe ser hacia estándares en lugar de productos específicos, buscando mantener un diseño eficiente que permita adaptarse a cambios en la base de datos.

• Se enfatiza que aunque se busca abstracción en el desarrollo orientado a objetos, esto no debe comprometer el rendimiento del sistema.

Manejo Práctico del SQL

Flexibilidad ante Cambios

• La propuesta es pensar lógicamente en las aplicaciones para evitar problemas cuando cambien motores o arquitecturas.

• A veces será necesario escribir SQL directamente por su rapidez en comparación con otras soluciones más complejas.

Técnicas Avanzadas

• Aunque algunas técnicas pueden parecer "chanchadas", se busca implementar soluciones polimórficas que permitan flexibilidad sin impacto significativo.

• No existe un estándar uniforme para acceder a todas las plataformas de persistencia; cada una tiene sus ventajas y desventajas.

Herramientas Necesarias

Uso de Frameworks

• Es necesario utilizar herramientas como Spring o Quarcus para obtener capas de transparencia al interactuar con bases de datos.

• Además del conocimiento técnico básico, se requiere entender conceptos como inyección de dependencias e inversión de control.

¿Cómo afecta la persistencia por alcance en las soluciones de mapeo?

Dependencias en el código y persistencia

• El orador menciona que no tiene una dependencia explícita en el código, pero sí requiere que cualquier mapeador o solución de persistencia tenga "persistencia por alcance".

• Se destaca que la mayoría de las soluciones de persistencia cuentan con esta característica, aunque no hacen suficiente publicidad al respecto.

Publicidad y uso de tecnologías

• Se plantea la idea de que empresas como Hibernate podrían no promover su funcionalidad de "persistencia por alcance" para evitar que los usuarios migren a otras soluciones más fácilmente.

• La creencia del orador es que si se hiciera más evidente esta característica, podría facilitar un cambio hacia otras tecnologías, lo cual sería menos favorable para Hibernate.

Cierre y disponibilidad futura

• El orador pregunta si hay más consultas sobre el tema antes de cerrar la sesión, indicando que habrá más días para discutir estos temas.

• Se menciona la decisión de finalizar la grabación y compartirla a través del foro y grupo correspondiente.