.net - Argumentos para la elección de uso: RavenDB vs SQL Server: rendimiento, confiabilidad y simplicidad

sql-server

Question

¿Qué puntos se deben tener en cuenta al elegir la capa de datos para una aplicación web?

¿Hay alguna opción preferible para usar la base de datos de documentos en lugar de las relacionales, mientras se desarrolla un proyecto pequeño sobre grandes y pesados, o viceversa?

¿Qué tipo de arquitectura de base de datos se prefiere para estos enfoques? Si tengo una base de datos simple sin demasiadas relaciones, ¿es mejor usar un enfoque sobre otro?

Answer 1

Dado que esta pregunta está invitando a comentarios personales, aquí está mi opinión :

SQL Server no es una base de datos para almacenar nada, excepto datos de informes ad-hoc. Es espléndido para eso, informes ad-hoc, minería de datos, descubrimiento de relaciones en tiempo real, y es óptimo para estos usos porque hace mucho tiempo cuando Codd diseñó las reglas, para eso fue diseñado (vea The Data Driven Conspiracy para más información). detalles)

Por supuesto, puede almacenar otros tipos de datos en una base de datos relacional. Por ejemplo, puede serializar su estado de dominio a una base de datos de SQL Server y recuperar ese estado en una fecha posterior, pero este es un uso terrible de un sistema relacional. Tan malo, de hecho, que se requieren capas enteras de código (las denominadas ''capas de datos'' o DAL), muchos miles de líneas, para hacer que este tipo de tarea sea factible, verificable y mantenible de forma remota.

El gran truco de confianza de décadas ha sido para los minoristas basados ​​en SQL para convencernos de que no había una mejor manera de almacenar datos jerárquicos / documentos aparte de la conversión en tiempo real entre estructuras de datos radicalmente diferentes. Todos los DAL y el último ORM han sido pregonados pero, al final, estos no son más que códecs para repartir los bits entre diferentes organizaciones de datos, diferentes patrones en el disco.

¡Locura!

Así que olvídate de todos los argumentos de los ángeles en una cabeza de alfiler sobre la atomicidad, la consistencia, el aislamiento, la durabilidad. El elefante en la habitación es que si está utilizando SQL Server y no es una compañía farmacéutica que está extrayendo dinámicamente cubos de datos en busca de inferencias ocultas en grandes poblaciones (¿lo está?), Entonces probablemente esté utilizando la tecnología incorrecta para almacenar sus datos. .

Si, por otro lado, eres un humilde desarrollador de aplicaciones, un programador que, como la mayoría de nosotros, simplemente desea serializar el dominio-estado de una manera que no signifique aprender un nuevo conjunto de ideologías y sintaxis para el bien. bien, no utilice una base de datos relacional. Simplemente no

RavenDB? He estado usando esto por un tiempo (habiendo evolucionado a través de DB4O y CouchBase) y puedo decir que hace lo que dice en la lata. Almacena mis cosas y me las devuelve cuando pregunto. No tuve que escribir ninguna capa de datos ni utilizar un ORM de terceros. No tuve que aprender un lenguaje de consulta estructurado y no tuve que utilizar los extras para que la búsqueda de texto completo funcionara (RavenDB se basa en Lucene, por lo que todo "simplemente funciona"). Hasta ahora tan bueno.

Pero realmente, ¿importa lo que use mientras sea, para la tarea en cuestión, fácil de codificar, rápido y eficiente? Para el desarrollo normal de aplicaciones, RavenDB es todas estas cosas, mientras que SQL Server no lo es. Eso no quiere decir que los DB relacionales sean malos, no culpemos a la víctima, reconozco que, para ciertos desarrollos especializados, es posible que necesite algo un poco más ... exótico, como un almacén de datos relacional.

Pero en caso de que aún esté aferrado a los restos, debe preguntarse esto: si todos hubiéramos estado usando almacenes de datos simples, rápidos y elegantes que se ajustaran a nuestras necesidades como desarrolladores de aplicaciones, y luego escribí un artículo de opinión instándole a Adopte SQL Server, entonces lo más probable es que se ría de mí o me compadeciera. Una cosa es segura: no cambiaría a SQL Server. Por lo tanto, demostramos que solo la inercia es la fuerza guía que mantiene a SQL Server en la corriente principal. Inercia e ignorancia. Inercia, ignorancia y avaricia corporativa.