NoSQL dentro de SQL Server

Esta pregunta no se trata de la diferencia entre SQL y NoSQL. Estoy buscando alguna razón para algo que realmente no tiene sentido para mí en este momento (tal vez debido a mi falta de comprensión o apreciación).

Hemos comenzado un nuevo proyecto desde cero utilizando MVC5, primero el código de Entity Framework 6 y SQL Server 2008. Cuando el arquitecto revisó el esquema de la base de datos, se afirmó que todas las claves externas y otras restricciones similares deberían eliminarse ya que esto es "lógica de negocios" y debe aplicarse dentro de la capa empresarial del código de la aplicación.

Mi opinión es que las claves externas forman parte de los datos / integridad referencial y realmente no imitan la lógica empresarial. Veo la lógica empresarial como más el proceso y la validación que controla qué / cuándo / cómo / por qué se aplican las referencias. Puedo entender que las restricciones únicas son posiblemente procesos de negocios, pero para mí esto solo complementa la lógica y forma parte de la integridad.

Un segundo argumento es que el objetivo es adoptar un enfoque NoSQL para los datos. Encontré esto realmente inusual y poco ortodoxo: teniendo en cuenta el uso de SQL-Server 2008, la necesidad de informar, los datos no escalan a terabytes y la falta de consideración hacia tecnologías como Mongo, Raven, etc.

¿Alguien se ha encontrado con tal escenario antes? ¿Por qué alguien adoptaría un enfoque NoSQL en un servidor SQL diseñado para datos referenciales y no querría claves externas?

sql sql-server nosql

— Andy Clark
fuente

Hable con su arquitecto de sistemas sobre la lógica de sus consejos. O tiene una muy buena razón que se aplica a su caso específico (una razón que no necesariamente podremos adivinar, sin saber exactamente en qué consiste su aplicación), o simplemente es incompetente.

— Arseni Mourzenko

He visto muchas bases de datos implementadas de manera similar: sin FKs, sin restricciones CHECK, cada vez que fueron bases de datos diseñadas por codificadores inexpertos que no sabían nada sobre arquitectura de bases de datos, integridad referencial, etc. Pero es importante que lo discutas con su colega, en lugar de simplemente asumir que es incompetente.

— Arseni Mourzenko

Estoy un poco confundido; menciona que usa Entity framework (primero el código) ... eso no implica que cree Objetos (en el sentido de C #) y luego deje que Entity framework se encargue de construir los equivalentes de la base de datos, en cuyo caso tratar de agregar / eliminar FK, etc. es un ejercicio para tratar de burlar a Entity Framework (que es algo así como la cita de Mark Twain acerca de tratar de enseñar a un cerdo a cantar)

— Foon

Hay demasiadas personas que se dicen "arquitectos", pero que en realidad no tienen experiencia en codificar o mantener sistemas más grandes.

— Doc Brown

Relevante: thedailywtf.com/articles/The-Mythical-Business-Layer . "Si lo piensa, prácticamente todas las líneas de código en una aplicación de software son lógicas comerciales". Esto se extiende a la base de datos. "Pero es igual de importante, si no más, tener en cuenta que casi todo el código de una aplicación será lógica de negocios. Ya existen suficientes herramientas; su aplicación no necesita una capa genérica " (énfasis mío). La persona que recomienda esto probablemente está tratando de convertir la base de datos en una de esas capas genéricas. En resumen, lo más probable es que pongan palabras de moda por encima de la realidad.

— jpmc26

Respuestas:

Cuando revisó el esquema de la base de datos, declaró que todas las claves foráneas y otras restricciones similares deberían eliminarse, ya que esta es la lógica empresarial y debería aplicarse dentro de la capa empresarial.

Entonces es un idiota, y es probable que algún extracto de su base de código termine algún día en The Daily WTF . Tienes toda la razón en que su enfoque no tiene sentido, y francamente tampoco su explicación.

Intente explicarle que las restricciones de integridad referencial no son "lógica de negocios"; son un estándar de corrección con su propia verificación incorporada. La lógica empresarial se trata de lo que haces con los datos; La integridad consiste en garantizar que los datos en sí no estén corruptos. Y si eso no funciona ... bueno, él está a cargo. Puedes seguir su plan e intentar mitigar un poco el daño, o comenzar a buscar un mejor lugar para trabajar. (O ambos.)

— Mason Wheeler
fuente

Tuve una respuesta un poco más diplomática que trató de encontrar una razón (sensata) por la cual el arquitecto podría estar haciendo esto. En una reflexión sobria, me estoy sumando a esta respuesta.

— Blrfl

Whoa whoa, los malos intentos de arquitectura son una razón para ir a trabajar a otro lado? Maldición, nunca hubiera podido seguir trabajando en ningún lado si adoptara esa perspectiva.

— Kzqai

@Kzqai también está el arquitecto fundamentalmente malentendido la arquitectura. Esto comienza a sonar como la directiva 595 y sí, si alguien quisiera obligarme a usar martillos para poner tornillos en una pieza de madera, encontraré a alguien que no me obligue a usar mal las herramientas para construir algo.

La integridad referencial es un tema central en la teoría de bases de datos, por no mencionar todas las bases de datos que lo admiten en el mundo real. Claramente, el compañero de trabajo de Andy es correcto en su análisis, el resto del mundo académico y profesional está 100% equivocado. Puntos de bonificación por mencionar The Daily WTF .

@AndyClark Deberías renunciar por esto. La razón es que es una bomba de tiempo nuclear en el núcleo de su empresa. Es solo cuestión de tiempo cuando la materia fecal incide sobre el ventilador. Cuando eso suceda, sería afortunado de trabajar en un turno de 72 horas, en el peor de los casos, estaría buscando un trabajo ... mejor buscar un trabajo cuando tiene un ingreso.

— ArTs

Todavía tengo que tener una razón para crear una clave foránea

- Joel Spolsky

Dejando a un lado las declaraciones generales, vale la pena reconocer que existen razones legítimas y fuertes para elegir no usar restricciones de unicidad o claves externas. La mayoría dice algo como esto:

Actuación. Hacer verificaciones de integridad con transacciones atómicas no es gratis. Y con frecuencia, la base de datos es la parte más difícil de escalar de su arquitectura. Quizás ya haya realizado las comprobaciones en la lógica de su aplicación y prefiera no incurrir en un segundo golpe de rendimiento.
Falta de necesidad Quizás sus datos estén sucios, y usted está de acuerdo con eso. Esto depende mucho de lo que estás haciendo.

Consulte también ¿Qué hay de malo con las claves foráneas?

Pero esos no coinciden con los motivos en su pregunta.

Esta es la lógica empresarial y debe aplicarse dentro de la capa empresarial.

Esta razón es un poco extraña. La singularidad y otras restricciones de integridad son en gran medida el dominio de una base de datos ACID. El código de su aplicación no puede acercarse a las garantías de atomicidad e integridad de SQLServer. Si necesita una integridad de datos sólida, sería una tontería ignorar la base de datos.

Un segundo argumento es que quieren adoptar el enfoque NoSQL para su almacenamiento de datos y, por lo tanto, no quieren que se apliquen tales restricciones.

La segunda razón no es realmente una razón; Es una conclusión. Aunque es cierto que las restricciones son una compensación entre la corrección y el rendimiento, y el sesgo de las bases de datos NoSQL hacia este último.

Tal vez el arquitecto de su sistema tenga en cuenta estas razones legítimas y haya escuchado mal. O tal vez es un idiota chiflado.

En cualquier caso, existen razones válidas (aunque no universales) para abstenerse de usar restricciones de unicidad y clave externa.

PD: si concluye que no desea claves foráneas, todavía está bien usar una base de datos relacional. Como generalización, las bases de datos relacionales son más maduras que sus contrapartes NoSQL. Como un solo nodo, incluso pueden ser más rápidos , y se puede construir una abstracción NoSQL sobre ellos .

— Paul Draper
fuente

Me atrevo a decir que Joel no es un idiota, pero una respuesta ingeniosa en un podcast, sin ninguna explicación es, en mi humilde opinión, vale menos que una declaración de cualquier idiota.

— Martin Ba

Joel es un tipo de hoja de cálculo, no un tipo de base de datos, por lo que su ignorancia de las prácticas estándar de bases de datos relacionales es, supongo, no sorprendente ... Sin ofender, Joel. :-)

— Eric King

La cita real en contexto de Joel es que las tecnologías, como LINQ, proporcionan una razón para molestarse en configurar una clave externa. Joel no es administrador de bases de datos y, al buscar en su blog y ser un lector de mucho tiempo, no puedo encontrar nada de él hablando sobre el tema o tratando de dar consejos sobre cómo optimizar bases de datos, diseñar modelos de datos, etc. Joel es increíble , pero ahora no lo es, ni lo ha sido nunca, ni lo ha afirmado. - un experto en el área de bases de datos o modelado de datos. Es como citar a Einstein sobre el interés compuesto, o, para el caso, los sándwiches. (Referencia de XKCD, de

— nada

Joel Spolsky es conocido por tener opiniones fuertes y controvertidas. Ver FogBugz está escrito en un lenguaje propietario ; La inyección de dependencia es demasiado complicada (por cierto, esta fue la respuesta más controvertida en Stackoverflow antes de ser cerrada) ; Las bases de datos XML son lentas ; etc.

— BlueRaja - Danny Pflughoeft

@BlueRaja: Umm ... Las bases de datos XML son lentas, particularmente en comparación con las bases de datos relacionales. ¿Desde cuándo es controvertido o una opinión?

— Mason Wheeler