¿Cómo sé que mis datos son de naturaleza relacional u orientada a objetos?

Solo lee estas líneas

• Si sus datos son de naturaleza objeto, utilice almacenes de objetos ("NoSQL"). Serán mucho más rápidos que una base de datos relacional.

• Si sus datos son de naturaleza relacional, la sobrecarga de una base de datos relacional lo vale.

desde-

http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

Entonces, ¿cómo sé si mis datos son de naturaleza relacional u orientados a objetos?

A riesgo de que me disparen, intentaré una definición simple en inglés.

La "naturaleza relacional" para mí se traduce en: todos los elementos de un tipo particular tienen prácticamente los mismos atributos, lo que hace que sea bastante fácil diseñar una tabla simple, pero todos los elementos en esa tabla y luego SQL para realizar CRUD y recuperación. Además, si sus datos pueden modelarse de manera que todos los elementos tengan uno de un conjunto limitado de tipos, puede definir una estructura de datos relacionales que corresponda a este conjunto de tipos.

La "naturaleza del objeto" se traduce en: Los elementos de tipo similar pueden tener una amplia variedad de atributos, y estos atributos pueden ser de una gran variedad en naturaleza y tipo. Muy a menudo esto podría (con suficiente esfuerzo) traducirse en un modelo relacional, pero muchas de las tablas estarían muy poco pobladas y terminaría con uniones LEFT OUTER muy ineficientes, lo que hace que el rendimiento de una base de datos relacional sea lento en comparación a una base de datos NOSQL.

Debo decir que desde mi punto de vista no hay una línea estricta que separe a estos dos. Probablemente puedas encontrar cualquier número de ejemplos que se encuentren entre los dos extremos.

Bien, ahora me he abierto a francotiradores desde todas las direcciones. Cualquier comentario bienvenido. Veamos si podemos mejorar juntos esta definición.

Los datos son ambos.

(estrictamente hablando, no puede ser objeto en la naturaleza porque carece de comportamiento, pero no vamos a criticar).

Las decisiones sobre el almacenamiento de datos en una base de datos RDBMS o NoSQL dependen más de cómo pretende utilizar los datos , en lugar de la "naturaleza" real de los datos en sí.

Si tiene la intención de admitir todo tipo de rutas de navegación a los datos, es posible que desee almacenar los datos en un RDBMS porque tendrá diferentes formas de acceder y presentar los datos. Necesita la base de datos para hacer mucho trabajo pesado por usted. Por ejemplo, se puede acceder a los datos de 'Pedido' a través del cliente, vendedor, sku (artículo), fecha, región, etc.

Por otro lado, si tiene rutas de navegación mínimas, puede almacenar todo el objeto. Por ejemplo, 'Basket' al que solo se accede desde el front-end web y no se almacena por mucho tiempo ni se analiza mucho, puede ser más adecuado para una tienda NoSQL. El sacrificio que hace con los almacenes de datos NoSQL (documento o valor clave) es que lo hace sin relaciones entre colecciones, si no necesita esas relaciones (para rutas de navegación, consultas o informes ad-hoc) y cuide de ellas en su aplicación, entonces estarás bien.

Por supuesto, puede almacenar datos en ambos por diferentes razones, pero eso tiene sus propios inconvenientes.

Los datos no son 'objeto en la naturaleza' o 'relacional en la naturaleza'. Cualquier tipo de datos puede representarse en una estructura de modelo / gráfico relacional o de objeto. Lo apropiado depende de cómo las aplicaciones utilizarán los datos. A menudo incluso puedes tener ambos. Por ejemplo, los datos utilizados en un sitio web podrían almacenarse en una base de datos relacional, pero a pedido cargados en una estructura gráfica que luego se almacena en caché en un almacén de valores clave en memoria.

La afirmación de que el objeto almacena / NoSql será más rápido que relacional para algunos tipos de datos es simplemente incorrecta. Lo que importa es nuevamente cómo su aplicación usa los datos, no la forma de los datos en sí. Un almacén de objetos será más rápido al cargar un gráfico de objetos almacenado como una unidad, pero será mucho más lento al realizar consultas ad-hoc en muchos objetos o actualizar propiedades en muchos objetos.

Creo que la línea clave del artículo es:

"Likewise, sometimes the output will be a single object X, which is easy to represent. But sometimes the output will be a grid of aggregate data, or a single integer count"

Me parece que el autor está haciendo un buen punto en que si su código es, por ejemplo, obtener el Número de clientes en España por un poco de lógica, no debe completar una lista de clientes con todos los clientes en España y luego contar El cliente se opone. (hacia el cual un ORM podría empujarlo)

Obviamente, desde la propia estructura de datos del cliente no se puede saber si se utilizará de esa manera. así que creo que deberíamos interpretar que "datos" significa "Toda la información utilizada por su aplicación". Si esto incluye cosas como agregados o 'Todo X relacionado con Y', entonces sus 'datos' no son adecuados para el enfoque atómico NoSql