Hay muchas otras condiciones de las que he estado escuchando con los sistemas no relacionales frente a los relacionales. Prefiero esta terminología a sql/no-sql porque personalmente creo que describe mejor las diferencias, y varios de los servidores "no-sql" tienen complementos de sql, así que de todos modos... qué tipo de patrón de concurrencia o aislamiento de transacciones es requerido en su sistema. Una de las supuestas diferencias entre dbs rel y no rel es "consistente siempre", "consistente en su mayoría" o "consistente eventualmente". Las bases de datos de relación por defecto generalmente caen en la categoría "en su mayoría consistentes" y con algo de trabajo, y una gran cantidad de condiciones de bloqueo y carrera,;) pueden ser "consistentes siempre" para que todos siempre busquen la representación más correcta de un dato dado. La mayor parte de lo que he leído/escuchado sobre dbs no rel es que son principalmente "consistentes-eventualmente". Esto significa que puede haber muchas instancias de nuestros datos flotando, por lo que el usuario "A" puede ver que tenemos 92 widgets en el inventario, mientras que el usuario "B" puede ver 79, y es posible que no se reconcilien hasta que alguien realmente vaya. para sacar cosas del almacén. Otro problema es la mutabilidad de los datos, ¿con qué frecuencia es necesario actualizarlos? Las bases de datos no rel particulares a las que he estado expuesto tienen más gastos generales para las actualizaciones, algunas de ellas tienen que regenerar todo el conjunto de datos para incorporar cualquier actualización.
Ahora mente, creo que non-rel/nosql son excelentes herramientas si realmente coinciden con su caso de uso. Tengo varios que estoy investigando ahora para proyectos que tengo. Pero debe tener en cuenta todas las compensaciones al tomar la decisión, de lo contrario, se convierte en un desarrollo más impulsado por el currículum.
