Primero, cualquier discusión sobre “X vs Y” donde X e Y son nombres de productos y X es significativamente diferente de Y muestra falta de consideración e indica que el autor escuchó algunas palabras clave y no sabe nada más que eso. Si esta pregunta se ha formulado como “base de datos relacional versus no relacional”, la percibiría de manera diferente, pero lo más importante ahora sería comprender los principios básicos de la base de datos. Asi que:
- No tiene que hacer una elección, puede usar ambos al mismo tiempo. En algún momento, probablemente tendrá que hacerlo: la mayoría de los sitios en los que he estado trabajando hasta ahora eventualmente se volvieron lo suficientemente complejos como para requerir características de ambos lados.
- Esto cambia la pregunta a “¿cuál debo usar para qué?” o “dada la aplicación en la que estoy trabajando, ¿puede alguno de ellos cumplir con todos los requisitos conocidos?”.
De cualquier manera, la base de datos está definida por los requisitos de la aplicación, por lo que no puede discutir la elección de la base de datos sin especificar sus casos de uso exactos. - Las bases de datos relacionales son como martillos: son buenas para la mayoría de los clavos, y una no es muy diferente de la otra en términos de modelo de datos y operaciones compatibles. Esto los convierte en un buen punto de partida si no tienes idea.
También a pequeña escala es más fácil emular características no relacionales en db relacional que de otra manera. - Las bases de datos no relacionales son como destornilladores hechos para tornillos muy específicos: si necesita uno, no puede usar ningún otro. En algún momento obtendrás una colección de varios de ellos, utilizados para fines muy específicos. No puede usar un destornillador plano genérico para tornillos en forma de estrella, y no puede usar uno en forma de inicio para tornillos triangulares.
- Cuando debe tener una base de datos relacional:
– almacena datos que controla, conoce bien y necesita garantías estrictas sobre su integridad (por ejemplo: si tiene una identificación de usuario en un lugar, debe existir un usuario con esta identificación, y cualquier intento de insertar uno que no exista debe fallar)
– estás usando transacciones
– espera que la base de datos realice operaciones complejas que modifican o extraen datos y escribir código que extrae datos de db y hace lo mismo no es una opción (caso de uso: tiene un tipo de informe que puede escribir algunos sql, pero nada más, y sucede ser tu jefe)
– su modelo de datos encaja perfectamente en tablas y columnas y no excede la capacidad de un solo servidor - Cuando debe tener una base de datos no relacional:
– sus datos no se ajustan al modelo relacional (ejemplo: búsqueda de texto completo, almacenamiento en caché, contadores)
– no conoce ni controla sus datos (ejemplo: extraer algo de proveedores externos que puede cambiar en cualquier momento y solo accede a parte de ellos)
– sus datos no caben en un solo servidor (considero la replicación y el fragmentación como una forma de base de datos no relacional)
– tiene requisitos de rendimiento específicos que el modelo relacional no puede cumplir - Por supuesto, hay un área gris donde podría usar cualquiera, pero es bastante pequeña.
En ese caso, sugeriría db relacional, ya que es una solución más madura y menos propensa a errores.
