Justificacion MySQL - jsyh1/practica_aplicada GitHub Wiki

Justificación del uso de MySQL para la persistencia de información

1. Características de MySQL relacionadas con las necesidades del sistema

El sistema requiere una base de datos que permita almacenar y consultar de forma estructurada la información generada por la aplicación (por ejemplo, puntajes, partidas, y en general entidades con relaciones bien definidas entre sí). MySQL ofrece las siguientes características alineadas con esas necesidades:

  • Modelo relacional maduro: permite representar entidades y sus relaciones mediante tablas, claves primarias y foráneas, lo cual encaja directamente con el diseño de clases del dominio (por ejemplo, la relación entre una partida y su puntaje).
  • Tipos de datos ajustados al dominio: tipos numéricos, de fecha/hora y de texto que cubren los campos típicos de la aplicación (puntajes, fechas de partida, identificadores).
  • Amplia adopción y documentación: al ser una de las bases de datos relacionales más usadas, existe abundante documentación, controladores JDBC estables y soporte de la comunidad.

2. Justificación técnica de su selección

Se seleccionó MySQL frente a otras alternativas por las siguientes razones técnicas:

  1. Curva de aprendizaje y disponibilidad de recursos: es una de las bases de datos más documentadas y enseñadas en el contexto académico, lo que reduce el riesgo de bloqueos técnicos durante el desarrollo.
  2. Compatibilidad directa con JDBC: Java ofrece un driver oficial (mysql-connector-j) maduro y bien mantenido, que se integra sin fricción con la clase db encargada de la conexión (conectar(): Connection).
  3. Costo y licenciamiento: MySQL Community Edition es de uso gratuito bajo licencia GPL, lo cual es adecuado para un proyecto académico sin presupuesto de licenciamiento.
  4. Herramientas de administración: cuenta con herramientas gráficas (MySQL Workbench) que facilitan el diseño del modelo entidad-relación y la depuración de consultas durante el desarrollo.
  5. Escala adecuada al alcance del proyecto: el volumen de datos esperado (partidas, puntajes de usuarios) no exige una base de datos distribuida o NoSQL; un motor relacional tradicional es suficiente y más simple de mantener.

3. Ventajas y limitaciones frente a otras alternativas

Alternativa Ventajas de MySQL frente a ella Limitaciones de MySQL frente a ella
PostgreSQL Configuración más simple para casos de uso básicos; amplia difusión en entornos educativos PostgreSQL ofrece soporte más avanzado para tipos de datos complejos (JSON, arrays) y consultas analíticas más sofisticadas
SQLite Soporta múltiples conexiones concurrentes y un motor de base de datos independiente del proceso de la aplicación, más adecuado si se necesita un servidor centralizado SQLite es más liviano y no requiere servidor, ideal solo para aplicaciones locales de un único usuario
MongoDB (NoSQL) Garantiza integridad referencial y consistencia transaccional (ACID), esencial cuando los datos tienen relaciones estrictas MongoDB ofrece mayor flexibilidad de esquema, útil si los datos fueran altamente variables o no estructurados, que no es el caso aquí
Oracle DB / SQL Server Sin costo de licenciamiento, más simple de instalar y administrar en un entorno académico Estos motores ofrecen funcionalidades empresariales avanzadas (particionamiento, alta disponibilidad nativa) que exceden lo que necesita este proyecto

Limitaciones generales de MySQL a tener en cuenta:

  • Menor soporte nativo para tipos de datos semiestructurados en comparación con PostgreSQL.
  • En escenarios de escritura muy intensiva y alta concurrencia a gran escala, otros motores pueden ofrecer mejor rendimiento sin ajuste adicional.

4. Compatibilidad con las tecnologías utilizadas en el proyecto

  • JavaFX: al ser la conexión gestionada desde una clase de servicio independiente (co.edu.poli.servicios.db), no existe acoplamiento entre el motor de base de datos y la capa de presentación; JavaFX simplemente consume los datos ya procesados por el modelo.
  • Maven: el driver de MySQL se integra como una dependencia estándar en el pom.xml, sin necesidad de configuración adicional fuera del archivo de propiedades del proyecto.
  • Arquitectura en capas del proyecto: al seguir el patrón MVC, la conexión a MySQL queda encapsulada en la capa de servicios/DAO (db, DaoScoreImplementado), sin exponer detalles de persistencia al controlador ni a la vista.

5. Consideraciones de seguridad, rendimiento, integridad y escalabilidad

Seguridad

  • Uso de conexiones autenticadas con usuario y contraseña, evitando el uso de la cuenta root en producción.
  • Uso de sentencias preparadas (PreparedStatement) en lugar de concatenación de cadenas SQL, para prevenir inyección SQL.
  • Restricción de privilegios del usuario de la aplicación solo a las operaciones necesarias (lectura/escritura sobre las tablas del sistema).

Rendimiento

  • Uso de índices sobre las columnas más consultadas (por ejemplo, identificadores de usuario o partida).
  • Reutilización de conexiones mediante un patrón de conexión controlado (evitar abrir/cerrar conexión en cada operación).
  • Consultas simples y acotadas al alcance actual del sistema, sin necesidad de optimizaciones avanzadas por el momento.

Integridad

  • Uso de claves primarias y foráneas para mantener la consistencia entre entidades relacionadas.
  • Restricciones (NOT NULL, UNIQUE) para reforzar reglas de negocio directamente en el esquema.

Escalabilidad

  • El volumen de datos esperado por el sistema (registros de partidas y puntajes) es manejable por una instancia estándar de MySQL sin necesidad de particionamiento o réplicas.
  • Si el proyecto creciera, MySQL permite escalar verticalmente (más recursos al servidor) o mediante réplicas de lectura, sin cambiar el modelo de datos actual.

6. Referencias a documentación oficial y fuentes técnicas