Comment arrêter de penser & # 8220; relationnellement & # 8221;

Question

Au travail, nous avons récemment démarré un projet utilisant CouchDB (une base de données orientée document). J'ai eu du mal à ne pas apprendre toutes mes connaissances relationnelles de la base de données.

Je me demandais comment certains d’entre vous ont surmonté cet obstacle? Comment avez-vous cessé de penser relationnellement et commencé à penser de manière documentaire (je m'excuse d'avoir inventé ce mot).

Des suggestions? Conseils utiles?

Éditer : si cela change quelque chose, nous utilisons Ruby & amp; CouchPotato pour se connecter à la base de données.

Éditer 2 : SO m'a alors harcelé pour accepter une réponse. J'ai choisi celui qui m'a le plus aidé à apprendre, je pense. Cependant, il n’existe pas de véritable " correct " répondez, je suppose.

Answer 1

Après avoir parcouru plusieurs pages à ce sujet, je pense que tout dépend du type de données à traiter.

Les SGBDR représentent une approche descendante dans laquelle vous, le concepteur de base de données, affirmez la structure de toutes les données qui existeront dans la base de données. Vous définissez qu'une personne a un prénom, un prénom, une adresse personnelle, etc. Vous pouvez appliquer cela à l'aide d'un SGBDR. Si vous n'avez pas de colonne pour HomePlanet d'une personne, ne vous voulez pas être une personne qui a une HomePlanet différente de celle de la Terre; vous devrez ajouter une colonne ultérieurement ou les données ne peuvent pas être stockées dans le SGBDR. De toute façon, la plupart des programmeurs font de telles suppositions dans leurs applications, alors ce n’est pas une chose stupide à supposer et à appliquer. Définir les choses peut être bon. Toutefois, si vous devez vous connecter à d'autres attributs ultérieurement, vous devrez les ajouter. Le modèle de relation suppose que vos attributs de données ne changeront pas beaucoup.

"Cloud" tapez des bases de données en utilisant quelque chose comme MapReduce, dans votre cas CouchDB, ne faites pas l'hypothèse ci-dessus, mais examinez plutôt les données de bas en haut. Les données sont entrées dans des documents, qui peuvent avoir un nombre quelconque d'attributs variables. Cela suppose que vos données, par leur définition même, sont diverses dans les types d'attributs qu'elles pourraient avoir. Il dit: "Je sais juste que j'ai ce document dans la base de données Personne qui possède un attribut HomePlanet de" Eternium ". et un prénom de "Lord Nibbler" mais pas de nom de famille. " Ce modèle convient aux pages Web: toutes les pages Web sont un document, mais le contenu / balises / clés du document varie tellement que vous ne pouvez pas les insérer dans la structure rigide sur laquelle le SGBD pontifie. C’est la raison pour laquelle Google pense que les modèles Roxors de MapReduce sont des soxors, car le jeu de données de Google est si diversifié qu’il doit créer une ambiguïté dès le départ, et grâce aux jeux de données volumineux, il est possible d’utiliser le traitement en parallèle (ce que MapReduce rend trivial) . Le modèle de base de données de documents suppose que les attributs de vos données peuvent changer / vont beaucoup changer ou seront très diversifiés avec des "trous". et beaucoup de colonnes peu peuplées que l'on pourrait trouver si les données étaient stockées dans une base de données relationnelle. Bien que vous puissiez utiliser un SGBDR pour stocker des données de ce type, cela deviendra très rapidement très laid.

Pour répondre à votre question, alors: vous ne pouvez pas penser "relationnellement". du tout quand on regarde une base de données qui utilise le paradigme MapReduce. Parce qu’il n’a pas réellement de relation forcée. C'est une bosse conceptuelle qu'il vous faudra surmonter.

Un bon article dans lequel j'ai comparé et mis en contraste les deux bases de données est MapReduce: un grand pas en arrière , selon lequel les bases de données de paradigme MapReduce représentent un pas en arrière technologique et sont inférieures aux SGBDR. Je ne suis pas d'accord avec la thèse de l'auteur et soutiendrais que le concepteur de la base de données devrait simplement choisir celui qui convient le mieux à sa situation.

Answer 2

Tout est une question de données. Si vous avez des données qui ont le plus de sens sur le plan relationnel, un magasin de documents peut ne pas être utile. Un système basé sur des documents typique est un serveur de recherche. Vous disposez d’un très grand ensemble de données et souhaitez rechercher un élément / document spécifique, le document est statique ou versionné.

Dans une situation de type archive, les documents peuvent être littéralement des documents qui ne changent pas et ont des structures très flexibles. Cela n'a pas de sens de stocker leurs métadonnées dans des bases de données relationnelles, car elles sont toutes très différentes, de sorte que très peu de documents peuvent partager ces balises. Les systèmes basés sur des documents ne stockent pas les valeurs NULL.

Les données non relationnelles / de type document sont utiles lorsqu'elles sont dénormalisées. Cela ne change pas beaucoup ou vous vous souciez moins de la cohérence.

Si votre cas d'utilisation correspond bien à un modèle relationnel, il ne vaut probablement pas la peine de l'intégrer dans un modèle de document.

Voici un bon article sur les bases de données non relationnelles . .

Une autre façon de penser est qu'un document est une ligne. Tout ce qui concerne un document se trouve dans cette ligne et est spécifique à ce document. Les lignes sont faciles à diviser, donc la mise à l’échelle est plus facile.

Answer 3

Dans CouchDB, comme Lotus Notes, vous ne devriez vraiment pas penser à un document comme étant analogue à une ligne.

Au lieu de cela, un document est une relation (table).

Chaque document comporte un certain nombre de lignes - les valeurs de champ:

ValueID(PK)  Document ID(FK)   Field Name        Field Value
========================================================
92834756293  MyDocument        First Name        Richard
92834756294  MyDocument        States Lived In   TX
92834756295  MyDocument        States Lived In   KY

Chaque vue est une requête de tableau croisé qui sélectionne un très grand UNION ALL de chaque document.

Donc, cela reste relationnel, mais pas au sens le plus intuitif ni au sens qui compte le plus: des bonnes pratiques de gestion des données.

Answer 4

Les bases de données orientées document ne rejettent pas le concept de relations, mais permettent parfois aux applications de déréférencer les liens (CouchDB) ou même de prendre en charge directement les relations entre documents (MongoDB). Ce qui est plus important, c'est que les DODB sont sans schéma. Dans les stockages basés sur des tables, cette propriété peut être réalisée avec un surcoût important (voir la réponse de richardtallent), mais ici, cela est fait de manière plus efficace. Ce que nous devrions vraiment apprendre lorsque nous passons d'un SGBDR à un DODB, c'est d'oublier les tables et de commencer à penser aux données. C'est ce que simulateur de mouton appelle le " bottom-up " approche. C'est un schéma en constante évolution, et non pas un lit Procrustean prédéfini. Bien entendu, cela ne signifie pas que les schémas doivent être complètement abandonnés, sous quelque forme que ce soit. Votre application doit interpréter les données, en quelque sorte en restreindre la forme. Pour ce faire, vous pouvez organiser les documents en collections, créer des modèles à l'aide de méthodes de validation, mais c'est maintenant le travail de l'application.

Answer 5

peut-être devriez-vous lire ceci http://books.couchdb.org/relax/getting-started

Je viens de l'entendre et c'est intéressant mais je ne sais pas comment le mettre en œuvre dans l'application du monde réel;)

Answer 6

Vous pouvez essayer d’obtenir une copie de firefox et firebug et de jouer avec les fonctions map et réduire en javascript. En fait, ils sont plutôt cool et amusants, et semblent être la base de la façon de faire avancer les choses dans CouchDB

voici le petit article de Joel sur le sujet: http: //www.joelonsoftware .com / items / 2006/08 / 01.html