MrRick2 escribió:djlogan83 escribió:MrRick2 escribió:
La ecuación más sencillas es:
¿Se comenzó el desarrollo desde la BD? -> NO
¿La BD seleccionada es correcta? -> NO (Se eligió NoSQL, es decir la BD del juego es un archivo gigante de datos sin relaciones)
Por ende, todo lo que se ha hecho en torno a la BD que NO fue desarrollada desde los cimientos y que además, fue una mala elección en elegir MongoDB, hay que tirar a la basura si quisiéramos retomar el desarrollo de manera seria.
Esto, sin contemplar las miles de cosas que se han hecho a las apuradas y de manera concreta, no abstracta, dado que han estado desarrollando a las apuradas, sin dormir bien y bajo presión.
¿De qué m**** hablo?
Le pedí a ChatGPT que lo explique por mi, ya que la redacción no es lo mío:
Código Abstracto vs. Código Concreto (Funcional pero no bien hecho)
Ejemplo de la Vida Real:
Código Abstracto:
Imagina que quieres construir una estantería modular, donde cada estante puede ajustarse en altura y posición. Para hacerlo, utilizas piezas estándar y de alta calidad que pueden ensamblarse de diferentes maneras, permitiendo que la estantería se adapte a diferentes necesidades y espacios en tu hogar.
Modularidad: Las piezas son intercambiables y se pueden reorganizar fácilmente.
Calidad: Usas materiales duraderos que aseguran que la estantería resista el paso del tiempo.
Flexibilidad: Puedes ajustar la altura de los estantes según el tamaño de los objetos que quieres almacenar.
Reutilización: Puedes usar las mismas piezas para construir otras estructuras, como un escritorio o una unidad de almacenamiento.
Ventajas del Código Abstracto (Estantería Modular):
Adaptable a diferentes situaciones.
Fácil de mantener y modificar.
Reutilizable para otros propósitos.
Duradero y resistente a largo plazo.
Código Concreto (Funcional pero no bien hecho):
Ahora, imagina que decides construir una estantería rápidamente con piezas de madera y clavos que tienes a mano. No te preocupas por la modularidad ni la calidad de los materiales; solo quieres algo que sostenga tus libros ahora mismo.
Funcionalidad básica: La estantería sostiene los libros, pero no está bien diseñada.
Rigidez: No puedes ajustar la altura de los estantes; están fijos.
Materiales pobres: La madera es de baja calidad y los clavos pueden soltarse con el tiempo.
Poca durabilidad: La estantería puede colapsar si cargas demasiados libros o si intentas moverla.
Desventajas del Código Concreto (Estantería Rápida):
Difícil de adaptar a nuevas necesidades.
Requiere más esfuerzo para reparaciones o ajustes.
No es reutilizable para otros propósitos.
Menos duradera y confiable.
Hola compañero, ante todo darte las gracias por todo lo que has expuesto e informado.
Solamente comentar que a mí no me parece mal usar mongo, sobre todo por su velocidad a la hora de manejar datos.
Aunque no sea relacional puedes hacerla relacional con algún ODM tipo mongoose que facilita la vida.
Sobre todo si no va a ser online y no va a haber ningún problema en la duplicación de datos...
Por todo lo demás concuerdo al 100%. Esto está para empezar de cero. El problema es que que equipo va a querer trabajar con HP?
No me queda más remedio que ir parcheando a lo chapuzas.
De hecho en una optimización suya que subió, vi que se traía todos los datos de mongo y luego usaba un .find sobre todo el array.
Imagino que la db era enorme y no entiendo cómo no se traía los datos ya filtrados de mongo en vez de traerse todo y filtrarlos en el juego con el consiguiente impacto de rendimiento, cuando mongo lo mejor que tiene es precisamente eso...
Buenas! Gracias por compartir tu punto de vista.
Estamos de acuerdo que Mongo no es el problema en si (como pasa siempre, la tecnología no tiene la culpa), si no, el problema es como lo han utilizado.
En un juego de manager donde hay muchas relaciones, a mi parecer, se debe utilizar una bd relacional, ya que además de hacer consultas con todas sus relaciones (un club con sus jugadores, DTs, nacionalidad, etc) es lo mejor que podemos usar y evitar traer una bd de cientos de miles de datos y después buscar sobre esos datos, es una locura a mi forma de ver.
En mi caso he utilizado SQLite para traer todos los datos centrales y luego dejarlos en memoria, entonces luego busco un club por su ID, jugadores por su club, y como se me de la gana buscar, de manera optimizada y si mañana agrego una relación a un club (ej: su ciudad) simplemente agrego una tabla.
Básicamente, hacer un select es mucho más rápido que hacer un find en ciento de miles de datos y traer lo que se relacionen con un ID que ni siquiera está relacionado realmente, es propenso a muchos errores y ni hablar de la performance.
Pero para guardar el progreso del juego, si va muy bien un NoSQL, ya que necesitas guardar datos dinámicos.
Mongo es una gran BD, el problema es el enfoque que le han dado.