Estamos de vuelta con el estudio de David Vaquero sobre el uso de tecnologías web y esta vez tratamos las bases de datos. En su propio estudio David analiza el uso de tecnologías de bases de datos sobre el millón de sitios web proporcionado por Alexa, tomando además dominios españoles. Este trabajo nos sirve para comentar los resultados y explicar las diferencias entre las bases de datos relacionales como MySQL, Percona, MariaDB o PostgreSQL y las basadas en las llamadas noSQL, con MongoDB como principal protagonista y claramente orientadas a soluciones distribuidas y escalables.
En el episodio David explica con detalle las diferencias conceptuales de este tipo de base de datos y los usos a los que va dirigidos. Es una explicación muy útil para tener una idea global sobre estas tecnologías y lo crítico que puede resultar para el rendimiento y la escalabilidad de nuestros proyectos.
Tradicionalmente las bases de datos se han visto como una caja negra, con una abstracción muy elevada para evitar preocuparse en los detalles de acceso y manipulación de los datos. Esta abstracción libera a los profesionales de las complejidades del software, aunque la exigencia y naturaleza de ciertas aplicaciones requieren tener un control más exhaustivo de cómo funcionan, destacando la importancia de contar con profesionales que optimicen los sistemas.
3 respuestas a “Estudio sobre uso de bases de datos relacionales y NoSQL”
Hola!
Lo primero muchas gracias por el programa, no me pierdo ninguno, o no planeo hacerlo. Con esto de la cuarentena voy retrasado, acabo de escuchar este :).
Muy buena la explicación de David sobre las diferencias entre SQL y NoSQL se nota que se dedica a esto, vaya piquito. Aunque debo decir que estoy bastante en desacuerdo con su afirmación de que toda startup debe empezar con Mongo (o cualquier otra NoSQL, entiendo) para no ponerse palos en las ruedas. Pese a que toda su argumentación es cierta, todos los beneficios de una base de datos no relacional vienen subditados al modelado de los datos, para mi la mayor diferencia entre ambos tipos:
– SQL, construyes tu modelo de datos para que sea consistente basado en entidades, luego aplicas queries en función de las necesidades del negocio.
– NoSQL, conoces las necesidades del negocio y construyes tu modelo de datos basado en sus requisitos para optimizar las queries, idealmente una por acción.
IMO, meter una NoSQL en un entorno donde los requisitos son tan cambiantes como una startup puede ser un suicidio (lo digo por experiencia, maldita ElasticSearch). En mi opinión, lo mejor es poder usar los dos modelos para aprovechar las virtudes de ambos en donde aplique, como bien habéis dicho.
Perdón por contaros mi vida pero si no lo decía reviento. Un saludo.
Hola Rober! Muchas gracias por contarnos tu experiencia y por tu punto de vista. Está claro que hay que valorar bien el tipo de proyecto y tampoco dejarse llevar por soluciones más «cool». Las bases de datos relacionales siguen demostrando un gran rendimiento y a fin de cuentas no todos los proyectos serán el próximo Uber. Muchas gracias por escucharnos y por tu apoyo cafetero. Un abrazo.
Buenas Rober.
En mi caso lo de «domar al caballo» es como llamo yo a ponerle límites a las BBDD NoSQL. MArcar esos llímites para que las cosas no se vayan de madre. Si usal cualquier tipo de ORM, te lo permite hacer de una manera muy sencilla 🙂
Programa shakesperiano para hablar de las razones o sinrazones de usar tailwind CSS. Partimos del provocador artículo de nuestro provocador de cabecera, Andros Fenollosa y que lleva por título: “Razones para no usar Tailwind”. En este artículo Andros analiza algunas razones por las que no deberías usar Tailwind CSS para tus proyectos. Según comenta Andros, … Sigue
Tras una larga pausa vuelvo a las grabaciones del podcast. Para esta nueva etapa quiero hablar de la estupenda charla ofrecida por Ben Orenstein en la conferencia Laracon US 2023 titulada «Predictable Mistakes of the Developer-Turned-Founder». En esta presentación Ben aborda los retos habituales a los que se enfrentan los desarrolladores que pasan a desempeñar … Sigue
Camilo Chacón Sartori vuelve de nuevo al podcast con la compañía de Andros Fenollosa, para hablar de su último libro Principios de Programación, que se publicará próximamente. Camilo Chacón es doctorando en ciencias de la computación en IIIA-CSIC y en la Universitat Autònoma de Barcelona. Se define a si mismo como un «informático humanista» y además de … Sigue
Nos ponemos el mundo por montera con un episodio especial del podcast, grabado como nos gusta: con grabadora y frente a frente. Andros y Javier nos juntamos en las oficinas de CCSTech.io frente a la Plaza de Toros de Valencia para hacer un episodio veraniego. Después de una pausa en las grabaciones, volvemos con muchos … Sigue
Hola!
Lo primero muchas gracias por el programa, no me pierdo ninguno, o no planeo hacerlo. Con esto de la cuarentena voy retrasado, acabo de escuchar este :).
Muy buena la explicación de David sobre las diferencias entre SQL y NoSQL se nota que se dedica a esto, vaya piquito. Aunque debo decir que estoy bastante en desacuerdo con su afirmación de que toda startup debe empezar con Mongo (o cualquier otra NoSQL, entiendo) para no ponerse palos en las ruedas. Pese a que toda su argumentación es cierta, todos los beneficios de una base de datos no relacional vienen subditados al modelado de los datos, para mi la mayor diferencia entre ambos tipos:
– SQL, construyes tu modelo de datos para que sea consistente basado en entidades, luego aplicas queries en función de las necesidades del negocio.
– NoSQL, conoces las necesidades del negocio y construyes tu modelo de datos basado en sus requisitos para optimizar las queries, idealmente una por acción.
IMO, meter una NoSQL en un entorno donde los requisitos son tan cambiantes como una startup puede ser un suicidio (lo digo por experiencia, maldita ElasticSearch). En mi opinión, lo mejor es poder usar los dos modelos para aprovechar las virtudes de ambos en donde aplique, como bien habéis dicho.
Perdón por contaros mi vida pero si no lo decía reviento. Un saludo.
Hola Rober! Muchas gracias por contarnos tu experiencia y por tu punto de vista. Está claro que hay que valorar bien el tipo de proyecto y tampoco dejarse llevar por soluciones más «cool». Las bases de datos relacionales siguen demostrando un gran rendimiento y a fin de cuentas no todos los proyectos serán el próximo Uber. Muchas gracias por escucharnos y por tu apoyo cafetero. Un abrazo.
Buenas Rober.
En mi caso lo de «domar al caballo» es como llamo yo a ponerle límites a las BBDD NoSQL. MArcar esos llímites para que las cosas no se vayan de madre. Si usal cualquier tipo de ORM, te lo permite hacer de una manera muy sencilla 🙂
Un saludo
David