Agregó algunos detalles en los comentarios que deberían dar una respuesta suficiente aquí.
En primer lugar, está haciendo referencia al siguiente material, que es una pieza de la Guardian / MongoDB. The Guardian Customer Success con MongoDB
De ninguna manera “trataría de demostrar que tomó la decisión correcta” . Esta es una pieza de MongoDB que está alojada en su sitio web. La suposición inicial debería ser “están mintiendo” y luego intentas probar eso en su lugar. Conseguir un acuerdo sobre un argumento unilateral no es realmente una excelente manera de demostrar nada.
- ¿Hay páginas web o estudios que hayan cambiado la forma en que ves el mundo? Un ejemplo es que hay rubias en todas las razas y en todos los continentes.
- ¿Por qué necesitamos saber sobre diseño web?
- En el contexto de Tag Management, ¿qué es mejor: una infraestructura del lado del cliente o del lado del servidor?
- Para alguien nuevo en GitHub, ¿cómo puedo ganar tracción para mi proyecto?
- ¿Cuál es un mejor campo de arranque para el desarrollo completo de la pila: Devmountain o V School?
Para ser justos, puedo decir esto porque muchos de los “profesionales” enumerados en el artículo no son demostrables. Aquí hay un resumen rápido con citas del artículo (TLC).
- TLC: “MongoDB proporciona la flexibilidad para dar cuenta de la variación en la cantidad de detalles almacenados para los usuarios, dependiendo de con qué servicios interactúen” .
¿Por qué no usar EAV, que históricamente ha proporcionado este tipo de característica (modelo Entidad-atributo-valor)? - TLC: modelo de datos JSON .
Dicen que esto es muy importante. Bueno, oye, PostgreSQL tiene un conjunto completo de características JSON, ¿por qué no usarlas? (Funciones y operadores JSON)
¿Y por qué es realmente importante JSON? ¿Es porque estás creando un servicio REST? Básicamente, cada idioma principal puede convertir un montón de objetos en JSON con una biblioteca y una línea de código. Entonces ese no es realmente un punto válido. - TLC: “… les permite acceder fácilmente a documentos con estructuras radicalmente diferentes al mismo tiempo, y tienen la capacidad de cambiar esa estructura con el tiempo …”
Esto está completamente sobrevendido. Están hablando de un servicio central de identidad. Si ese servicio reestructura la forma en que devuelven los datos de identidad, otros dependientes claramente se romperán.
Imagínese si Facebook o Twitter cambiaron la estructura de sus datos devueltos. Otras partes comenzarían a fallar hasta que lo alcanzaran. De hecho, no tienes que imaginarte, esto ha sucedido muchas veces. Ambas partes ahora publican cambios importantes con semanas o meses de anticipación. - TLC: “El lenguaje de consulta de MongoDB facilita el acceso a los datos JSON”.
Nuevamente, Postgres también tiene un lenguaje de consulta. También tenga en cuenta que en realidad no hablan de rendimiento. Es bien sabido que MongoDB funciona muy mal cuando se realizan consultas no indexadas. De hecho, puede arrojar una excepción si realiza una consulta no indexada con una clasificación que es demasiado grande para que pueda manejarla. - TLC: “En comparación con la solución RDBMS anterior de The Guardian, que requería tiempo de inactividad al actualizar el esquema …”
De nuevo, ¿por qué no usaron EAV? Eso no habría requerido ningún tiempo de inactividad para las actualizaciones de esquema. ¿Por qué no usar PostgreSQL? Parece que en su mayoría solo están pasando objetos JSON “de vuelta a sí mismos”, por lo que esa opción no funciona tan bien.
Nada de esto demuestra un mejor resultado en tiempos de diseño o tiempos de implementación. El único reclamo relacionado con el tiempo es “menos tiempo de inactividad”.
También afirman ser capaces de “mantenerse por delante de la competencia” , pero no proporcionan ninguna evidencia sobre cómo “tomaron la delantera” o “se movieron más rápido”. Afirman “productividad mejorada del desarrollador”, pero en realidad no proporcionan ninguna evidencia de esto.
No hay una sola métrica, no hay una historia sobre cómo cambiar un proyecto de tiempo extra, no hay una historia que se encuentre por debajo del presupuesto o que reduzca drásticamente la cantidad de desarrolladores / personal de operaciones necesarios para entregar el producto.
Esta es literalmente la definición de una pieza de hojaldre. No hay una sola métrica útil en todo el artículo.
¿Eso resuelve tu problema de tarea?
