Comment savoir si mes données sont de nature relationnelle ou orientée objet?

Il suffit de lire ces lignes-

• Si vos données sont de nature objet, utilisez des magasins d'objets ("NoSQL"). Ils seront beaucoup plus rapides qu'une base de données relationnelle.

• Si vos données sont de nature relationnelle, la surcharge d'une base de données relationnelle en vaut la peine.

de-

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

Alors, comment savoir si mes données sont de nature relationnelle ou orientées objet?

Au risque de me faire tirer dessus, je vais essayer une définition anglaise simple.

Pour moi, la "nature relationnelle" se traduit par: tous les éléments d'un type particulier ont à peu près les mêmes attributs, ce qui facilite la conception d'une table simple, mais tous les éléments de cette table, puis SQL pour effectuer le CRUD et la récupération. De plus, si vos données peuvent être modélisées de manière à ce que tous les éléments aient l'un d'un ensemble limité de types, vous pouvez alors définir une structure de données relationnelle qui correspond à cet ensemble de types.

La «nature de l'objet» se traduit par: Les éléments de type similaire peuvent avoir une grande variété d'attributs, et ces attributs peuvent être d'une grande variété de nature et de type. Très souvent, cela pourrait (avec un effort suffisant) être traduit en un modèle relationnel, mais beaucoup de tables seraient très peu peuplées et vous vous retrouveriez avec des jointures LEFT OUTER très inefficaces, ce qui rend les performances d'une base de données relationnelle lentes par rapport à la comparaison à une base de données NOSQL.

Je dois dire que de mon point de vue, il n'y a pas de ligne stricte séparant ces deux. Vous pourriez probablement trouver un certain nombre d'exemples qui se situent n'importe où entre les deux extrêmes.

OK, alors maintenant je me suis ouvert aux tireurs d'élite de toutes les directions. Tous les commentaires sont les bienvenus. Voyons si nous pouvons améliorer cette définition ensemble.

Les données sont les deux.

(à proprement parler, il ne peut pas être un objet dans la nature car il manque de comportement, mais nous ne taperons pas).

Les décisions concernant le stockage des données dans une base de données SGBDR ou NoSQL dépendent davantage de la façon dont vous avez l' intention d'utiliser les données , plutôt que de la véritable «nature» des données elles-mêmes.

Si vous avez l'intention de prendre en charge toutes sortes de chemins de navigation vers les données, vous souhaiterez peut-être stocker les données dans un SGBDR car vous aurez différentes façons d'accéder et de présenter les données. Vous avez besoin de la base de données pour faire beaucoup de travaux lourds pour vous. Par exemple, les données de `` commande '' peuvent être accessibles via le client, le vendeur, le sku (article), la date, la région, etc.

D'un autre côté, si vous disposez de chemins de navigation minimaux, vous pouvez simplement stocker l'intégralité de l'objet. Par exemple, le «panier» qui n'est accessible que par le frontal Web et qui n'est pas stocké longtemps ou analysé beaucoup, peut être mieux adapté à un magasin NoSQL. Le sacrifice que vous faites avec (document ou valeur clé) les magasins de données NoSQL est que vous vous passer de relations entre les collections - si vous n'avez pas besoin de ces relations (pour les chemins de navigation, les requêtes ad hoc ou les rapports) et que vous en prenez soin dans votre application, alors tout ira bien.

Bien sûr, vous pouvez stocker des données dans les deux pour différentes raisons, mais cela a ses propres inconvénients.

Les données ne sont pas «de nature objet» ou «de nature relationnelle». Tout type de données peut être représenté à la fois dans une structure relationnelle ou dans un modèle objet / graphique. Ce qui est approprié dépend de la façon dont les données seront utilisées par les applications. Souvent, vous pourriez même avoir les deux. Par exemple, les données utilisées sur un site Web peuvent être stockées dans une base de données relationnelle, mais chargées à la demande dans une structure graphique qui est ensuite mise en cache dans un magasin de valeurs-clés en mémoire.

La déclaration que l'objet stocke / NoSql sera plus rapide que relationnelle pour certains types de données est tout simplement fausse. Ce qui importe, c'est encore une fois comment votre application utilise les données, pas la forme des données elles-mêmes. Un magasin d'objets sera plus rapide lors du chargement d'un graphe d'objets stocké en tant qu'unité, mais sera beaucoup plus lent lors des requêtes ad hoc sur de nombreux objets ou de la mise à jour des propriétés de nombreux objets.

Je pense que la ligne clé de l'article est:

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

Il me semble que l'auteur fait un bon point en ce que si votre code obtient par exemple le nombre de clients en Espagne pour un peu de logique, vous ne devez pas remplir une liste de clients avec tous les clients en Espagne et ensuite compter les objets du client. (vers lequel un ORM pourrait vous pousser)

De toute évidence, vous ne pouvez pas dire à partir de la structure de données client elle-même si elle sera utilisée comme ça. Je pense donc que nous devrions interpréter «données» comme signifiant «toutes les informations utilisées par votre application». Si cela inclut des choses comme les agrégats ou «Tous les X liés à Y», vos «données» ne conviennent pas à l'approche atomique NoSql