Comment faites-vous pas rejoint?

Question

Récemment, j'ai beaucoup lu sur la façon dont les jointures dans les requêtes de base de données ralentissent les choses. Evidemment, Google App Engine ne les autorise même pas.

Je me demande comment les gens conçoivent une application sans jointure. Par exemple, je travaille sur une application comportant contacts et organisations . Un contact peut être dans de nombreuses organisations et une organisation peut avoir de nombreux contacts. Comment serait-il possible d’avoir cette relation sans une troisième table reliant les deux entités ...

contacts --< contacts_organizations >-- organizations

Cela signifie-t-il que dans GAE, vous ne pouvez pas avoir une relation plusieurs à plusieurs? Vous venez de laisser de côté une fonctionnalité qui nécessiterait une jointure?

Je suppose que vous pourriez avoir une colonne TEXTE organisations dans la table contacts contenant une liste des identifiants d'organisation pour chaque contact, séparés par des espaces. Cela semble un peu bizarre cependant.

Answer 1

Habituellement, lorsque vous parlez de bases de données n'autorisant pas de jointures, vous parlez de bases de données très volumineuses qui ne tiennent pas nécessairement sur un serveur. Les exemples récents étant les bases de données cloud telles que SimpleDB d'Amazon , Les services de données SQL de Microsoft et Banque de données de Google App Engine . Certaines offrent une capacité de jointure limitée, mais la grande difficulté consiste à faire des jointures sur les partitions . " ;. Dans les bases de données volumineuses telles que celle-ci, vous partitionnez vos données afin qu'elles ne résident pas nécessairement sur le même serveur. Vous devez décider de la bonne façon de le partitionner.

Dans votre exemple, je stockais une liste de clés d'organisation dans un champ de la table des contacts, et inversement. La conception de ces bases de données est différente de celle de votre base de données normalisée classique. Les tables sont généralement des "tables clairsemées", ce qui signifie fondamentalement que chaque enregistrement peut avoir un nombre quelconque de champs qui sont essentiellement des paires nom / valeur. Pensez à une table de produits sur Amazon et au nombre de champs possibles pour différents types de produits. Les livres ont un nombre de pages, mais les MP3 ont une durée. Dans une table fragmentée, ces enregistrements seraient stockés dans la même table.

Answer 2

C’est un mythe qui associe les logiciels de ralentissement, de la même manière que ce serait un mythe de revendiquer des boucles d’écriture dans le code d’application des logiciels de ralentissement.

Je veux dire, pourquoi écrire une boucle? Cela exécute les mêmes lignes de code encore et encore! N'était-ce pas assez? C'est un énorme gaspillage!

Les déclarations ci-dessus se veulent ironiques.

Mon problème est qu'une requête contient une jointure dans le but d'obtenir la bonne réponse. Utiliser des jointures de manière inefficace ou inutile est bien sûr une mauvaise conception, comme insérer du code invariant d'une boucle dans une boucle.

Éviter les jointures en tant que stratégie générale est un exemple d'optimisation prématurée . Si votre approche de l'écriture de code efficace consiste à définir de telles règles, éviter les jointures ne vous aidera pas.

Quant à Google App Engine, il prend en charge les relations entre entités. Toutefois, comme il ne s'agit pas d'un modèle de base de données relationnelle, le concept de jointure n'apparaît pas vraiment. Au lieu de cela, vous pouvez obtenir des entités associées à partir d'une référence donnée, ce qui ressemble plus à une interface ORM à un modèle. Ce n'est pas la même chose qu'une jointure dans SQL.

Vous pouvez en lire plus ici: http://code.google.com/appengine/articles/modeling.html

(ce lien était dans une autre réponse sur ce fil, mais il a été supprimé)

Answer 3

Point de départ: Google n'interdit pas les JOINs dans sa base de données pour empêcher les utilisateurs de faire fonctionner le " coûteux " des requêtes; la base de données n’est pas relationnelle, donc la balise "JOIN". Le verbe SQL n'est pas vraiment applicable en premier lieu.

De cette façon, BigTable est identique à SimpleDB d'Amazon - les données sont dénormalisées et supprimées. schémas afin que vous vous retrouviez efficacement avec d'énormes tables de hachage efficaces avec des données arbitraires autorisées dans les compartiments.

Ces tables de hachage sont très, très faciles à mettre à l’échelle, en particulier par rapport aux bases de données relationnelles. Pour des applications telles que GAE, une évolutivité extrême est une priorité supérieure à un ensemble complet de fonctionnalités.

Answer 4

Vous utilisez db.ReferenceProperty pour lier des objets, voir Moteur Google App: identifiez-vous un à plusieurs pour plus de détails et des exemples.

Answer 5

Je pense que Google est en train de vous extraire un mécanisme très lourd en termes de calcul. Vous allez donc rechercher des moyens d'utiliser davantage d'autres types de ressources, par exemple des disques durs conservant des tables de référence et / ou des tables de comptage au lieu des cycles de calcul perdus pour jointure et calcul d'agrégat.

Et ce n'est pas impossible, il vous suffit de contourner ce problème en utilisant d'autres types de ressources pour vous aider.

Answer 6

Vous pouvez effectuer des jointures dans votre application plutôt que sur le serveur de base de données, en récupérant les résultats de chaque table séparément, puis en les combinant. Toutefois, pour la plupart des jointures, cela ne vous ralentira pas du fait de la latence des allers-retours entre bases de données. au lieu d'un seul.

Mais: la vérité est que les jointures ne sont pas votre problème. À ce moment-là, vous n'aurez même plus besoin de poser cette question. Vous pouvez compter le nombre de projets concrets qui arrivent à ce point sur vos doigts (principalement Ebay), et rien ne prouve que l’élimination complète des jointures était la seule façon dont ces projets auraient pu être réalisés à l’échelle.

Answer 7

Les bases de données que vous mentionnez sont, au mieux, des magasins de disques versionnés conçus pour stocker de très grands volumes de données sur plusieurs serveurs. Les appeler une "base de données" serait un effort. Ne supporte pas les jointures, ni les transactions ACID, les restaurations, etc. Vous pouvez écrire des applications sans elles mais vous devrez souvent faire plus de travail pour fournir les fonctionnalités.

Pour:

contacts --< contacts_organizations >-- organizations

Vous pouvez dé-normaliser et stocker les organisations dans les contacts et les contacts dans les organisations. Mais vous devrez appliquer l'intégrité référentielle dans le traitement de l'application avec une mise à jour simultanée vers les deux tables.

Une meilleure solution serait de stocker les données dans trois tables et de faire les jointures vous-même.