Como sei que meus dados são relacionais ou orientados a objetos por natureza?

Basta ler estas linhas

• Se seus dados são objetos na natureza, use armazenamentos de objetos ("NoSQL"). Eles serão muito mais rápidos que um banco de dados relacional.

• Se seus dados são de natureza relacional, vale a pena a sobrecarga de um banco de dados relacional.

a partir de-

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

Então, como sei se meus dados são relacionais por natureza ou orientados a objetos?

Correndo o risco de levar um tiro em pedaços, tentarei uma definição clara em inglês.

"Natureza relacional" para mim se traduz em: todos os itens de um tipo específico têm praticamente os mesmos atributos, o que facilita bastante o design de uma tabela simples, mas todos os itens nessa tabela e depois o SQL para executar CRUD e recuperação. Além disso, se seus dados puderem ser modelados de modo que todos os itens tenham um de um conjunto limitado de tipos, você poderá definir uma estrutura de dados relacionais que corresponda a esse conjunto de tipos.

"Natureza do objeto" se traduz em: itens de tipo semelhante podem ter uma grande variedade de atributos e esses atributos podem ter uma grande variedade de natureza e tipo. Muitas vezes, isso (com esforço suficiente) poderia ser traduzido em um modelo relacional, mas muitas das tabelas seriam muito escassamente preenchidas e você acabaria com junções LEFT OUTER muito ineficientes, o que torna o desempenho de um banco de dados relacional lento quando comparado para um banco de dados NOSQL.

Eu diria que, do meu ponto de vista, não existe uma linha estrita que separa esses dois. Provavelmente, você pode encontrar vários exemplos que se situam entre os dois extremos.

OK, agora me abri para atiradores de todas as direções. Quaisquer comentários bem-vindos. Vamos ver se podemos melhorar essa definição juntos.

Os dados são ambos.

(a rigor, não pode ser objeto da natureza porque não possui comportamento, mas não vamos escolher nada).

As decisões sobre o armazenamento de dados em um banco de dados RDBMS ou NoSQL dependem mais de como você pretende usá- los , e não da 'natureza' real dos dados em si.

Se você pretende oferecer suporte a todos os tipos de caminhos de navegação para os dados, convém armazenar os dados em um RDBMS, pois você terá maneiras diferentes de acessar e apresentar os dados. Você precisa do banco de dados para fazer muito trabalho pesado para você. Por exemplo, os dados do 'Pedido' podem ser acessados ​​via cliente, vendedor, sku (item), data, região etc.

Por outro lado, se você tiver caminhos de navegação mínimos, poderá armazenar apenas o objeto inteiro. Por exemplo, 'Basket', que é acessado apenas pelo front-end da web e não é armazenado por muito tempo ou muito analisado, pode ser mais adequado a um repositório NoSQL. O sacrifício que você faz com os armazenamentos de dados NoSQL (documento ou valor-chave) é que você fica sem relacionamentos entre coleções - se não precisar desses relacionamentos (para caminhos de navegação, consultas ad-hoc ou relatórios) e cuida deles em seu app, então você ficará bem.

Obviamente, você pode armazenar dados em ambos por diferentes razões, mas isso tem suas próprias desvantagens.

Os dados não são 'objeto da natureza' ou 'natureza relacional'. Qualquer tipo de dado pode ser representado na estrutura relacional ou no modelo de objeto / gráfico. O que é apropriado depende de como os dados serão usados ​​pelos aplicativos. Muitas vezes você pode até ter os dois. Por exemplo, os dados usados ​​em um site podem ser armazenados em um banco de dados relacional, mas sob demanda, carregados em uma estrutura gráfica, que é armazenada em cache em um armazenamento de valores-chave na memória.

A declaração de que o objeto armazena / NoSql será mais rápida que relacional para alguns tipos de dados está simplesmente errada. O que importa é novamente como seu aplicativo usa os dados, não a forma dos dados em si. Um armazenamento de objetos será mais rápido no carregamento de um gráfico de objetos armazenado como uma unidade, mas será muito mais lento nas consultas ad-hoc em vários objetos ou na atualização de propriedades em muitos objetos.

Eu acho que a linha principal do artigo é:

"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"

Parece-me que o autor está afirmando que, se o seu código, por exemplo, está obtendo o número de clientes na Espanha por um pouco de lógica, você não deve preencher uma lista de clientes com todos os clientes na Espanha e depois contar os objetos do cliente. (para o qual um ORM pode empurrá-lo)

Obviamente, você não pode dizer pela própria estrutura de dados do cliente se será usado dessa maneira. então, acho que devemos interpretar 'dados' como 'Todas as informações usadas pelo seu aplicativo'. Se isso inclui coisas como agregados ou 'Todo X relacionado a Y', então seus 'dados' não são adequados para a abordagem NoSql atômica