Pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter, inscrivez-vous gratuitement !

 

  1. #1
    Nouveau Candidat au Club
    Profil pro
    Inscrit en
    décembre 2008
    Messages
    3
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2008
    Messages : 3
    Points : 1
    Points
    1

    Par défaut Jointure ou jsonb indexé

    La question des jointures et la performance revient souvent.
    Toutefois j'ai une question particulière pour laquelle j'ai du mal à trouver un retour d'expérience.

    Prenons l'exemple d'une table contenant des informations sur de nombreux produits.
    Ces produits disposent d'infos de base identiques pour tous les produits. Ce sont donc des colonnes de la table.
    Ces produits peuvent aussi avoir des attributs supplémentaires très variables.

    Pour stocker ces attributs, on a plusieurs possibilités :
    - utiliser une table d'attributs liées à la table produit
    - utiliser un champ d'attributs jsonb en tant que colonne de la table produit

    Ma question concerne les recherches au sein de la table produit sur un nombre très grands de produits et avec environ 50 attributs par produit.
    Imaginons que l'on souhaite trouver tous les produits ayant l'attribut couleur à la valeur rouge.

    Aura-t-on de meilleures performances avec une architecture utilisant 2 tables ou avec une seule table (et un index GIN sur la colonne des attributs jsonb) ?
    Et si différence il y a, quelle est son ordre de grandeur ?

    Merci par avance.

  2. #2
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 070
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 070
    Points : 42 273
    Points
    42 273

    Par défaut

    Il y a différentes solutions pour différents cas.
    Les différents cas sont liés à la fréquences des mises (INSERT, UPDATE, DELETE) à jour et/ou des recherches (SELECT et dans une moindre mesure UPDATE et DELETE).

    En gros il faut se rapprocher plutôt du relationnel si beaucoup de mise à jour.

    Note que le format de stockage JSON ne présente aucun intérêt ni pour l'un, ni pour l'autre cas par rapport à du XML... En effet, le modèle DOM est natif en XML ce qui n'est pas le cas du JSON qu'il faut "convertir" en XML pour avoir une représentation DOM.

    C'est pourquoi les bon SGBDR savent indexer du XML au niveau PATH, PROPERTY ou VALUE, mais ne proposent pas ce type de service au niveau du JSON...

    Dans tous les cas, PostGreSQL ne sait ni indexer du XML ni du JSON, donc, toutes les recherches seront lentes...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  3. #3
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 530
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Mali

    Informations professionnelles :
    Activité : Recherche, formation, développement

    Informations forums :
    Inscription : août 2006
    Messages : 1 530
    Points : 3 286
    Points
    3 286
    Billets dans le blog
    8

    Par défaut

    Salut
    Citation Envoyé par SQLpro Voir le message
    Dans tous les cas, PostGreSQL ne sait ni indexer du XML ni du JSON, donc, toutes les recherches seront lentes...
    On s'informe avant de raconter des mensonges.
    PostgreSQL indexe bien le type json au format binaire (jsonb)[/URL], format d'ailleurs précisé dans la demande. On peut aussi indexer une expression XPATH pour le type XML.
    Pour répondre à yoandm...
    • A défaut de "retour d'expérience", Il faut faire vos propres essais pour conclure. (En faire un article si possible)
    • Pour l'option du json, il serait mieux d'avoir deux tables : produit (idp, ...), propriete(idp, prorpriete en json). Cela assouplira les traitements de la table produit.

    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  4. #4
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 070
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 070
    Points : 42 273
    Points
    42 273

    Par défaut

    Citation Envoyé par alassanediakite Voir le message
    Salut

    On s'informe avant de raconter des mensonges.
    PostgreSQL indexe bien le type json au format binaire (jsonb), format d'ailleurs précisé dans la demande.
    Désolé de te le dire aussi cruement, mais l'indexation GIN (utilisée aussi pour le XML) est une vaste merde. Comme elle forme un dictionnaire de paire clef valeur, elle permet juste de savoir si telle ou telle clef existe, mais pas de la situer efficacement (chemin) ni de faire l'inverse efficacement, c'est à dire retrouver la ou les clefs à partir d'une valeur...
    Encore une fois il ne s'agit pas de dire il est possible de poser des index dans du JSON, mais que ces index servent à quelques chose en pratique dans l'exploitation...

    C'est un peu comme MySQL qui dit qu'il fait tout... Mais comme il fait tout mal, ça sert à rien en pratique !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  5. #5
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 530
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Mali

    Informations professionnelles :
    Activité : Recherche, formation, développement

    Informations forums :
    Inscription : août 2006
    Messages : 1 530
    Points : 3 286
    Points
    3 286
    Billets dans le blog
    8

    Par défaut

    Salut
    S'il te plait, prend le temps de lire pour éviter les incohérences...
    Citation Envoyé par SQLpro Voir le message
    ...elle forme un dictionnaire de paire clef valeur, elle permet juste de savoir si telle ou telle clef existe, mais pas de ... retrouver la ou les clefs à partir d'une valeur
    A quoi bon alors de stocker clé et valeur?
    En ce qui concerne la recherche de position, je ne vois aucun intérêt avec le json ou le xml. Si tu veux tel degré de recherche utilise plutôt le full text.
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  6. #6
    ced
    ced est déconnecté
    Rédacteur/Modérateur

    Avatar de ced
    Homme Profil pro
    Gestion de bases de données techniques
    Inscrit en
    avril 2002
    Messages
    5 769
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : Gestion de bases de données techniques
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : avril 2002
    Messages : 5 769
    Points : 22 918
    Points
    22 918

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    mais l'indexation GIN (utilisée aussi pour le XML) est une vaste merde. Comme elle forme un dictionnaire de paire clef valeur, elle permet juste de savoir si telle ou telle clef existe, mais pas de la situer efficacement (chemin) ni de faire l'inverse efficacement, c'est à dire retrouver la ou les clefs à partir d'une valeur...
    Personnellement, je ne l'aurais pas exprimé dans ces termes... Pas besoin d'être vulgaire...
    Effectivement, l'indexation GIN indexe les clés, pas les valeurs.
    Par contre, cette indexation ne se limite quand même pas seulement à savoir "si telle ou telle clef existe", mais également où elle se trouve.
    Rédacteur / Modérateur SGBD et R
    Mes tutoriels et la FAQ MySQL

    ----------------------------------------------------
    Pensez aux balises code et au tag
    Une réponse vous a plu ? N'hésitez pas à y mettre un
    Je ne réponds pas aux questions techniques par message privé, les forums sont là pour ça

  7. #7
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 530
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Mali

    Informations professionnelles :
    Activité : Recherche, formation, développement

    Informations forums :
    Inscription : août 2006
    Messages : 1 530
    Points : 3 286
    Points
    3 286
    Billets dans le blog
    8

    Par défaut

    Salut ced
    Citation Envoyé par ced Voir le message
    Effectivement, l'indexation GIN indexe les clés, pas les valeurs.
    Que doit-on comprendre alors dans la documentation paragraphe 8.14.4. Indexation jsonb
    Les index GIN peuvent être utilisés pour chercher efficacement des clés ou paires clé/valeurs se trouvant parmi un grand nombre de documents (datums) jsonb. Deux « classes d'opérateur » GIN sont fournies, offrant différents compromis entre performance et flexibilité.

    La classe d'opérateur GIN par défaut pour jsonb supporte les requêtes avec des opérateurs clé-existe au niveau haut ?, ?& et des opérateurs ?| et l'opérateur chemin/valeur-existe @>.
    Plus loin dans le même paragraphe...
    Mais il faut noter qu'un tel index stockera des copies de chaque clé et chaque valeur de la colonne jdoc, alors que l'index sur expression de l'exemple précedent ne stockera que les données trouvées pour la clé tags. Alors que l'approche d'index simple est bien plus souple (puisqu'elle supporte les requêtes sur n'importe quelle clé), les index sur des expression ciblées ont bien plus de chances d'être plus petits et plus rapide pour la recherche qu'un simple index.
    Si vous faites allusion au fonctionnement de GIN...
    GIN est l'acronyme de Generalized Inverted Index (ou index générique inverse). GIN est prévu pour traiter les cas où les items à indexer sont des valeurs composites, et où les requêtes devant être accélérées par l'index doivent rechercher des valeurs d'éléments apparaissant dans ces items composites. Par exemple, les items pourraient être des documents, et les requêtes pourraient être des recherches de documents contenant des mots spécifiques.

    Nous utilisons le mot item pour désigner une valeur composite qui doit être indexée, et le mot clé pour désigner une valeur d'élément. GIN stocke et recherche toujours des clés, jamais des items eux même.

    Un index GIN stocke un jeu de paires de (clé, posting list), où posting list est un jeu d'adresse d'enregistrement (row ID) où la clé existe. Le même row ID peut apparaître dans plusieurs posting lists, puisqu'un item peut contenir plus d'une clé. Chaque clé est stockée une seule fois, ce qui fait qu'un index GIN est très compact dans le cas où une clé apparaît de nombreuses fois.
    A ma compréhension (parlant de jsonb), "item" de GIN désigne un document json et "clé" de GIN désigne une entrée "clé:valeur" OU une "clé" du document json selon le choix de l'opérateur de l'index (cf: explication ci-dessus).
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  8. #8
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 070
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 070
    Points : 42 273
    Points
    42 273

    Par défaut

    Citation Envoyé par ced Voir le message
    Personnellement, je ne l'aurais pas exprimé dans ces termes... Pas besoin d'être vulgaire...
    Effectivement, l'indexation GIN indexe les clés, pas les valeurs.
    Par contre, cette indexation ne se limite quand même pas seulement à savoir "si telle ou telle clef existe", mais également où elle se trouve.

    CORRECTION :pas "ou elle se trouve", mais "ou elles se trouvent". En effet en cas de pluralité d'une balise, la recherche GIN en sus d'être moins efficace sortira toutes les occurrences.

    Exeplique moi comment tu te tire de cette affaire :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    CREATE TABLE T_J (K SERIAL PRIMARY KEY, J JSON);
     
    INSERT INTO T_J (J) VALUES 
    ('{
      "rac": {
        "bal1": { "ballot": "rantanplan" },
        "bal2": { "ballot": "lucky luke" }
      }
    }');
    Extraire, avec utilisation de l'index, la valeur de la base "ballot" relative à bal1 => "rantanplan"

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    CREATE INDEX X_XML ON T_J USING gin (J jsonb_path_ops);
    Déjà ceci ne fonctionne pas :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    ERROR:  ERREUR:  la classe d'opérateur « jsonb_path_ops » n'accepte pas le type de données json
    SQL state: 42804
    
    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  9. #9
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 070
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 070
    Points : 42 273
    Points
    42 273

    Par défaut

    Citation Envoyé par alassanediakite Voir le message
    Salut ced

    Que doit-on comprendre alors dans la documentation paragraphe 8.14.4. Indexation jsonb

    Plus loin dans le même paragraphe...


    Si vous faites allusion au fonctionnement de GIN...

    A ma compréhension (parlant de jsonb), "item" de GIN désigne un document json et "clé" de GIN désigne une entrée "clé:valeur" OU une "clé" du document json selon le choix de l'opérateur de l'index (cf: explication ci-dessus).
    @+

    Donc on est bien d'accord, aucune recherche directe de valeur n'est possible.
    Indexation de clef, ou paire clef valeur, mais pas d'indexation de valeur sans clef.
    De la même manière une clef n'est pas un chemin.
    Donc, aucune indexation de chemin n'est possible

    Ce sont bien les limitations que je t’ai données... (pour le XML, le JSON revenant au même (XML <=> JSON).

    Au lieu de te focaliser sur PostgreSQL, regarde ce que font les autres SGBDR en la matière...
    Par exemple :
    dans Oracle tu peux indexer les chemins, les positions hiérarchiques des balises et les valeurs
    http://www.ksi.mff.cuni.cz/~svoboda/...-Oracle-DB.pdf
    Dans SQL Server, tu peux indexer les positions hiérarchiques des nœuds avec leur type (index XML primaire), les chemins, les valeurs et les propriétés (soit 4 types d'index)
    https://docs.microsoft.com/fr-fr/sql...xes-sql-server

    Si tu devais indexer tous les chemins dans PostGreSQL tu devrais connaître les chemins à l'avance et s'il y a 1000 chemins, créer mille index sur fonction... !!!!

    C'est donc stupidement inefficace

    Et dans le cas de notre ami, l'absence d'index sur valeur rend toute jointure avec une valeur exprimée sous forme JSN d'une extrême inefficacité.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  10. #10
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 530
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Mali

    Informations professionnelles :
    Activité : Recherche, formation, développement

    Informations forums :
    Inscription : août 2006
    Messages : 1 530
    Points : 3 286
    Points
    3 286
    Billets dans le blog
    8

    Par défaut

    Salut
    Citation Envoyé par SQLpro Voir le message
    Donc on est bien d'accord, aucune recherche directe de valeur n'est possible.
    J'ai vraiment de la peine à imaginer une requête cherchant une VALEUR dans le json ou le xml sans préciser la CLE ou le CHEMIN.
    Le reste du message n'a pas plus d’intérêt.
    Un petit demo...
    J'ai créé une table avec du jsonb...
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    CREATE TABLE pjsonb (
        idp integer NOT NULL,
        prenomp character varying(30),
        nomp character varying(30),
        parent jsonb
    );
    et insérer des données de cette manière...
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    INSERT INTO pjsonb (idp, prenomp, nomp, parent) VALUES (x, 'xx', 'yyy', '{"mere": {"nom": "iii", "prenom": "uuu"}, "pere": {"nom": "ooo", "prenom": "eee"}}');
    plus un index
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    CREATE INDEX idxgin ON personne.pjsonb USING gin (parent);
    Ci-joint le dump de 2615 lignesdump.zip
    Tu peux faire tes essaies avec les requêtes du genre...
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    explain analyse select * from pjsonb where parent @>'{"mere":{"prenom":"Aminata"}}'::jsonb
    et comparer les performances.
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  11. #11
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 070
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 070
    Points : 42 273
    Points
    42 273

    Par défaut

    Citation Envoyé par alassanediakite Voir le message
    Salut

    J'ai vraiment de la peine à imaginer une requête cherchant une VALEUR dans le json ou le xml sans préciser la CLE ou le CHEMIN.
    La plupart du temps, c'est justement pour le retrouver !!!!

    Un petit exemple simple dans SQL Server...
    Microsoft SQL Server constitue les plans d'exécution de ses requêtes sous forme XML. Un petit exemple :
    https://tomaztsql.files.wordpress.co...ng?w=618&h=417
    Un tel plan peut faire plusieurs centaines de milliers de balises...
    SQL Server conserve des dizaines de milliers de plan en mémoire pour les réutiliser mais aussi pour les diagnostics post exploitation...
    Un diagnostic très intéressant est de retrouver tous les plans contenant un "warning" c'est à dire une condition de génération du plan qui informe d'un problème potentiel...
    Associé à un module nommé Query Store qui analyse en permanence ces plans et surtout leur réutilisation au fil du temps, ces extractions permettent d'améliorer sensiblement la détection des requêtes mal écrites...

    Pense tu que cela ne serve à rien ???

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  12. #12
    Nouveau Candidat au Club
    Profil pro
    Inscrit en
    décembre 2008
    Messages
    3
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2008
    Messages : 3
    Points : 1
    Points
    1

    Par défaut

    Bonjour,

    J'étais en vacances et je viens prendre connaissance de vos réponses.
    Déjà, merci pour ces retours que je vais analyser avec soin.

    En revanche, je ne pensais pas générer autant d'échanges musclés avec cette question :-)

    Encore merci.

  13. #13
    Nouveau Candidat au Club
    Profil pro
    Inscrit en
    décembre 2008
    Messages
    3
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2008
    Messages : 3
    Points : 1
    Points
    1

    Par défaut

    J'avoue que j'espérais beaucoup de cette combinaison JSONB et GIN après les quelques lectures d'articles à ce sujet.
    Que pensez-vous de cet article : https://blog.2ndquadrant.com/jsonb-t...ostgresql-9-4/ ?

    Merci à vous.

  14. #14
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 070
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 070
    Points : 42 273
    Points
    42 273

    Par défaut

    Citation Envoyé par yoandm Voir le message
    J'avoue que j'espérais beaucoup de cette combinaison JSONB et GIN après les quelques lectures d'articles à ce sujet.
    Que pensez-vous de cet article : https://blog.2ndquadrant.com/jsonb-t...ostgresql-9-4/ ?

    Merci à vous.
    L'article que vous mentionnez est intéressant... Mais la boite qui l'a publié "second quandrant" est spécialisé sur PostgreSQL et ne travaille que sur ce moteur. Un peu comme si vous demandiez à un garagiste qui ne vend que des Renault, si les performances des Renault dont bonnes....
    De plus le volume des données indiqué : "209MB and contains approximately 600k" tient en RAM même sur un smartphone.... Qu'en sera t-il avec une base de plusieurs Go ?
    Pour info, 1,1 s pour ce traitement sans index est totalement inacceptable. Et 0.167ms une foi indexé aussi !
    Aucune comparaison n'est faite avec la solution non JSON....
    Pour moi cet article est à mettre à la poubelle !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  15. #15
    Futur Membre du Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mai 2017
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2017
    Messages : 8
    Points : 8
    Points
    8

    Par défaut

    Un peu comme si vous demandiez à un garagiste qui ne vend que des Renault, si les performances des Renault dont bonnes....
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Sans commentaire.

    Pour info, 1,1 s pour ce traitement sans index est totalement inacceptable.
    En anglais, 1.100ms signifie 1,1 ms et non 1,1 s.

  16. #16
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    15 802
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 15 802
    Points : 31 246
    Points
    31 246
    Billets dans le blog
    4

    Par défaut

    Revenons au besoin exprimé...
    Prenons l'exemple d'une table contenant des informations sur de nombreux produits.
    Ces produits disposent d'infos de base identiques pour tous les produits. Ce sont donc des colonnes de la table.
    Ces produits peuvent aussi avoir des attributs supplémentaires très variables.

    Pour stocker ces attributs, on a plusieurs possibilités :
    - utiliser une table d'attributs liées à la table produit
    - utiliser un champ d'attributs jsonb en tant que colonne de la table produit

    Ma question concerne les recherches au sein de la table produit sur un nombre très grands de produits et avec environ 50 attributs par produit.
    Règle de gestion :
    Un produit peut avoir plusieurs attributs et un attribut peut s'appliquer à plusieurs produits.

    MCD :
    Produit -0,n----avoir----0,n- Attribut

    Tables :
    te_produit_prd (prd_id, [autres colonnes communes à tous les produits]...)
    te_attribut_att (att_id, att_code, att_nom...)
    tj_prd_avoir_att_paa (paa_id_produit, paa_id_attribut, paa_valeur...)

    Imaginons que l'on souhaite trouver tous les produits ayant l'attribut couleur à la valeur rouge.
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    SELECT p.prd_id, p.prd_nom, p.prd_reference
    FROM te_produit_prd p
    INNER JOIN tj_prd_avoir_att_paa pa ON pa.paa_id_produit = p.prd_id
    	INNER JOIN te_attribut_att a ON a.att_id = pa.paa_id_attribut
    WHERE a.att_nom = 'couleur'
    	AND pa.paa_valeur = 'rouge'

    La jointure étant une opération très optimisée par les SGBD, cette requête devrait s'exécuter très rapidement, même avec plusieurs millions de lignes dans les tables.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

Discussions similaires

  1. Jointure sur un index à deux colonnes
    Par hbellahc dans le forum Adaptive Server Enterprise
    Réponses: 5
    Dernier message: 10/03/2011, 19h15
  2. Jointure simple qui ne passe pas par les index ?!
    Par souch dans le forum Oracle
    Réponses: 13
    Dernier message: 24/07/2007, 17h03
  3. probleme index bitmap de jointure, oracle 10g
    Par nagty dans le forum Oracle
    Réponses: 2
    Dernier message: 19/04/2006, 20h14
  4. [Index] Utilisation dans les jointures..
    Par argv666 dans le forum MS SQL-Server
    Réponses: 3
    Dernier message: 07/03/2006, 14h07
  5. Réponses: 2
    Dernier message: 21/07/2005, 12h05

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo