+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Community Manager

    Avatar de Malick
    Homme Profil pro
    Auditeur
    Inscrit en
    juillet 2012
    Messages
    4 708
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Auditeur
    Secteur : Conseil

    Informations forums :
    Inscription : juillet 2012
    Messages : 4 708
    Points : 54 306
    Points
    54 306
    Billets dans le blog
    15

    Par défaut PostgreSQL 9.5 disponible en version bêta 1, intégrant la correction de nombreux bogues

    PostgreSQL 9.5 est disponible en version bêta 1,
    et intègre la correction de nombreux bogues signalés depuis la version alpha 2

    Nom : logo-pgsql.png
Affichages : 4504
Taille : 9,6 Ko

    Le PostgreSQL Global Development Group a annoncé la sortie de la première version bêta de PostgreSQL 9.5. Cette dernière, selon l'éditeur, contient toutes les fonctionnalités et les API qui seront intégrées dans la version finale. Peu de modifications devraient intervenir.

    L'éditeur affirme qu’avec cette première version bêta de PostgreSQL 9.5, les utilisateurs peuvent maintenant tester leurs applications, cela en préparation de la version finale.

    Le PostgreSQL Global Development Group souligne également que cette nouvelle version du célèbre système de gestion de bases de données relationnelles et objets intègre plusieurs corrections de bogues qui avaient été signalés depuis la sortie de la version Alpha 2. Parmi les améliorations apportées, nous pouvons citer :
    • de nombreux ajustements à la sémantique du Row Level Security (RLS) ;
    • des améliorations des deadlocks avec LWLock ;
    • les problèmes de corruption d'index BRIN ;
    • les difficultés relatives à la connexion avec PGSSLMODE=require sous Windows ;
    • différents problèmes de traçage des timestamp de commit ;
    • les fuites de mémoire des hash join ;
    • le comportement incohérent de jsonb_set lors de l'ajout dans un tableau.

    L'éditeur souligne également la modification de la sémantique du Row Level Security pour plus de cohérence avec le système de permissions de PostgreSQL basé sur GRANT. À titre d’exemple, la RLS applique désormais à la fois les politiques d'INSERT et SELECT lorsque l'INSERT RETURNING est utilisé. Ceci étant, les utilisateurs sont invités à tester l'application des règles TLS et à retester toute configuration RLS existante afin de s’assurer qu’il n’y a pas de régression dans leurs cas d'utilisation.

    Le PostgreSQL Global Development Group ajoute que ceci est la première version bêta de la version 9.5 ; ce qui veut dire que très peu de changements visibles par l'utilisateur sont attendus avant la version finale. Le projet PostgreSQL publiera des bêtas supplémentaires requis pour les tests à venir, cela jusqu'à la sortie de la version finale prévue en fin de 2015.

    Téléchargez PostgreSQL 9.5 bêta 1

    Consultez la note de version

    Source : annonce officielle

    Et vous ?

    Que pensez-vous de cette nouvelle version bêta ?
    Allez-vous la tester ?

    Voir aussi :

    le Forum PostgreSQL
    Vous avez envie de contribuer au sein du Club Developpez.com ? Contactez-nous maintenant !
    Vous êtes passionné, vous souhaitez partager vos connaissances en informatique, vous souhaitez faire partie de la rédaction.
    Il suffit de vous porter volontaire et de nous faire part de vos envies de contributions :
    Rédaction d'articles/cours/tutoriels, Traduction, Contribution dans la FAQ, Rédaction de news, interviews et témoignages, Organisation de défis, de débats et de sondages, Relecture technique, Modération, Correction orthographique, etc.
    Vous avez d'autres propositions de contributions à nous faire ? Vous souhaitez en savoir davantage ? N'hésitez pas à nous approcher.

  2. #2
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    1 380
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 380
    Points : 38 423
    Points
    38 423
    Billets dans le blog
    2

    Par défaut PostgreSQL 9.5 disponible en téléchargement

    PostgreSQL 9.5 disponible en téléchargement
    Le SGBDRO embarque la fonction UPSERT et mise sur le Big Data et la sécurité

    Un an après la sortie de PostgreSQL 9.4, les utilisateurs du système populaire de gestion de bases de données relationnelles et objet (SGBDRO) PostgreSQL peuvent bénéficier d’une nouvelle version majeure. Le PostgreSQL Global Development Group vient en effet d’annoncer la sortie de PostgreSQL 9.5 en mettant en avant la fonction UPSERT, les politiques de Row Level Security, ainsi que des fonctionnalités Big Data.

    À la demande des développeurs, la fonction UPSERT (diminutif d’INSERT, ON CONFLICT UPDATE) est enfin implémentée dans PostgreSQL. D’après l’annonce officielle, cette fonction vise à « simplifier le développement d’applications web et mobiles en déléguant à la base de données la gestion des éventuels conflits lors de modifications concurrentes ». « La nouvelle clause ON CONFLICT permet d’ignorer certaines données ou de mettre à jour d’autres colonnes ou tables, de manière à supporter les traitements complexes lors de chargement de données avec un ETL. »

    Cette nouvelle version met encore l’accent sur la sécurité de vos données avec une nouvelle fonctionnalité appelée Row Level Security (RLS). Comme son nom peut l’indiquer, RLS permet une gestion des droits des utilisateurs par ligne et par colonne. Cela pourrait permettre d’offrir une meilleure résistance contre les attaques par injection SQL et les failles de sécurité au niveau applicatif.

    Côté Big Data, il faut retenir que PostgreSQL 9.5 est également conçu pour les grands volumes de données. Le SGBDRO intègre de nombreuses fonctionnalités Big Data. Entre autres, on peut noter par exemple la commande SQL TABLESAMPLE qui permet de renvoyer rapidement un échantillon des données d’une table. On retrouve encore trois nouvelles clauses issues de la norme SQL (CUBE, ROLLUP et GROUPING SETS) qui permettent aux utilisateurs de créer des rapports avec plusieurs niveaux d’agrégation de données en utilisant une seule requête SQL.

    PostgreSQL peut désormais effectuer les tris de données textuelles et NUMERIC plus rapidement sur de grands ensembles de données. Les requêtes qui font des tris peuvent être 2 à 12 fois plus rapides selon l’annonce officielle du PostgreSQL Global Development Group. La création d’index, quant à elle, se fera jusqu’à 20 fois plus vite. Cela a été rendu possible grâce à un algorithme appelé « abbreviated keys ». Comme autre nouveauté pour le traitement des grands volumes de données, on note aussi les index BRIN qui offrent une nouvelle méthode pour créer des index plus légers, mais plus efficaces sur les tables volumineuses et « naturellement ordonnées ».

    Déjà présents dans les versions précédentes de PostgreSQL, les Foreign Data Wrappers (FDW) s’améliorent dans cette nouvelle version. Les FDW permettent d’utiliser PostgreSQL comme un moteur de recherche pour des systèmes Big Data comme Hadoop et Cassandra. Dans la version 9.5, les développeurs du SGBDRO ajoutent la commande IMPORT FOREIGN SCHEMA et le transfert des ordres JOIN sur les serveurs distants. Cela permet de simplifier et optimiser l’accès aux sources de données externes.

    Plus de détails sur les nouveautés dans PostgreSQL 9.5 sont disponibles sur le site officiel. La nouvelle version est également disponible en téléchargement.

    Télécharger PostgreSQL 9.5

    Source : Blog PostgreSQL

    Et vous ?

    Utilisez-vous PostgreSQL ? Que pensez-vous de cette nouvelle version ?

    Voir aussi

    Forum PostgreSQL
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  3. #3
    Membre confirmé
    Homme Profil pro
    nop
    Inscrit en
    mars 2015
    Messages
    436
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : nop
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2015
    Messages : 436
    Points : 620
    Points
    620

    Par défaut

    UPSERT sert-elle à mettre à jour un enregistrement dans le cas où l'insertion serait un échec dû à un duplicat ?

    ou est-ce l'inverse ? c-a-d UPSERT permet de créer un tuple si on a essayé avec échec de mettre à jour un enregistrement dont l’id n'existe pas-plus ?

    Dans les deux, n'est-ce pas de la responsabilité du "bon développeur responsable" de s'assurer de l'existence ou de la non-existence d'un tuple (ou de son id) avant sa mise-à-jour/création.

  4. #4
    Membre éclairé
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    juin 2004
    Messages
    224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Belgique

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 224
    Points : 769
    Points
    769

    Par défaut

    La commande en PostGreSQL ne s'appelle pas UPSERT mais "ON CONFLICT UPDATE", qui est bien plus explicite je pense :-)

    Le cas d'utilisation est simplement lorsqu'on veut s'assurer que la donnée se trouvera dans la base de données, peu importe si elle était déjà présente ou pas. C'est parfois pratique, mais ça ne reste "que" du sucre syntaxique .

  5. #5
    Membre habitué
    Homme Profil pro
    Inscrit en
    septembre 2005
    Messages
    97
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Secteur : Arts - Culture

    Informations forums :
    Inscription : septembre 2005
    Messages : 97
    Points : 144
    Points
    144

    Par défaut

    Pour moi ça ressemble au INSERT... ON DUPLICATE UPDATE de MySQL, qui existe depuis longtemps

  6. #6
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    371
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 371
    Points : 511
    Points
    511

    Par défaut

    Avec l'instruction ON CONFLICT, on pourra remplacer ceci :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    CREATE FUNCTION upsert_user(u_name text, u_fullname text, u_email text) RETURNS integer
        LANGUAGE plpgsql
        AS $$
    DECLARE
        userid users.id_user%TYPE;
    BEGIN
        LOOP
            UPDATE users SET "fullname" = u_fullname, "email" = u_email WHERE "name" = u_name RETURNING "id_user" INTO userid;
            IF FOUND THEN
                RETURN userid;
            END IF;
            BEGIN
                INSERT INTO users ("name", "fullname", "email") VALUES (u_name, u_fullname, u_email) RETURNING "id_user" INTO userid;
                RETURN userid;
                EXCEPTION WHEN unique_violation THEN
     
            END;
        END LOOP;
    END;
    $$;
     
    SELECT * FROM upsert_user(`jdoe`, `John Doe`, `john.doe@developpez.com`);
    Par ceci :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    INSERT INTO users ("name", "fullname", "email")
    VALUES (`jdoe`, `John Doe`, `john.doe@developpez.com`)
    ON CONFLICT DO UPDATE SET "fullname" = `John Doe`, "email" = `john.doe@developpez.com`
    RETURNING "id_user";
    L'avantage est de ne pas être obligé de passer par une procédure stockée.
    Intéressant pour l'avenir, mais je ne vais pas pour autant modifier mes anciens projets.

  7. #7
    Membre confirmé
    Homme Profil pro
    nop
    Inscrit en
    mars 2015
    Messages
    436
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : nop
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2015
    Messages : 436
    Points : 620
    Points
    620

    Par défaut

    quelqu'un peut-il me dire dans quel cas fonctionnel, quelle situation (dans la vie réelle, dans une vraie application développée sérieusement), on arrive à un cas où l'on met à jour un enregistrement qui n'est pas existant (qui n'a pas d'id) ?

    ça semble être un moyen de dissimuler/amortir un bug produit dans l'application (qui met à disposition des enregistrements sans ID alors qu'elle ne devrait pas) ?
    Quelle situation de la vie d'un processus autoriserait un tel process : créer un ID quand une identité n'existe pas ... c'est bancal non ?

    Si on met à jour un enregistrement et que l'id n'existe pas, la moindre des choses est de retourner une erreur pour enquêter de la disparition de cet ID (ou du filtrage écran trop strict) plutôt que de recréer une identité.

  8. #8
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    371
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 371
    Points : 511
    Points
    511

    Par défaut

    Tu utilises généralement l'UPSERT pour intégrer un objet d'une base de données externe à ta base.
    Je l'utilise par exemple dans le cas de l'authentification Active Directory à l'IntraWeb PHP de la société : si l'utilisateur se connecte pour la première fois au système son nom de compte n'existe pas au sein de la base de données, mais tu cherches à obtenir la clé primaire dans la table users. Dans ce cas l'UPSERT insert une ligne et te renvoie l'id de la ligne insérée. Lorsqu'il se connectera pour la seconde fois il te renverra l'id de la ligne existante. Il en va de même pour les groupes auxquels cet utilisateur appartient, qui doivent exister localement pour servir au système de gestion d'accès de l'appli alors que leur création, modification et suppression ne se fait que dans Active Directory.

    Certains dans ce cas utiliseront deux requêtes distinctes et diront que l'UPSERT ne sert à rien, mais imagine un cas pratique très simple : le verrouillage du formulaire de login est défaillant et la requête est envoyée à deux reprises dans un intervalle très court (double clic sur le bouton d'envoi). Nous aurons donc 2 accès concurrents qui vont vérifier l'existence du nom d'utilisateur et chercher à le créer. Le premier réussira, mais le second va lever une exception. Pour faciliter cela on peut, grâce à l'implémentation du concept UPSERT (ON CONFLICT DO), gérer tout cela en une seule opération : insérer, sinon mettre à jour ou simplement récupérer.

  9. #9
    Modérateur
    Avatar de al1_24
    Homme Profil pro
    Ingénieur d'études décisionnel
    Inscrit en
    mai 2002
    Messages
    7 254
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études décisionnel
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 7 254
    Points : 22 008
    Points
    22 008

    Par défaut

    Il me semble que la commande MERGE apparue dans la norme SQL-2003 opère de manière semblable.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    MERGE INTO ma_table [AS] tgt
    USING ( requete ) [AS] src
    ON ( src.cle = tgt.cle )
    WHEN MATCHED THEN UPDATE SET tgt.col = src.col [, ...]
    WHEN NOT MATCHED THEN INSERT (cle, col [, ...]) VALUES (src.cle, src.col [, ...]);
    Je trouve dommage d'avoir créé une commande spécifique plutôt que se conformer à la norme.
    Modérateur Langage SQL
    Règles du forum Langage SQL à lire par tous, N'hésitez pas à consulter les cours SQL
    N'oubliez pas le bouton et pensez aux balises
    [code]
    Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
    Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.

  10. #10
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    371
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 371
    Points : 511
    Points
    511

    Par défaut

    Il existe plusieurs raisons à cela, mais la principale est que PostgreSQL se veut un SGBDR collant parfaitement à la norme SQL, ce qui fait qu'ils n'implémentent une instruction que lorsqu'ils sont sûrs de le faire de la bonne manière.
    Oracle et MSSQL utilisent la syntaxe du MERGE pour l'implémentation de l'UPSERT, mais la plupart des SGBDR ont préféré (comme c'est le cas pour PostgreSQL) de choisir un autre mot réservé car la norme SQL-2003 ne définit pas de manière précise le comportement de cette instruction.
    Si ce comportement devait être détaillé dans une future norme, ils ne veulent pas que leur implémentation du MERGE n'entre en conflit avec cette norme.

    Source : https://wiki.postgresql.org/wiki/UPS...tax_discussion

    MERGE disadvantages

    The SQL standard doesn't specify concurrency behaviour for MERGE any more than it does for INSERT, UPDATE, or DELETE; so (like other DML) our behavior with concurrent access may not be the same as other database products. In particular, the SQL standard does not require that MERGE be atomic in the sense of atomically providing either an INSERT or UPDATE, and other products do not provide any such guarantees with their MERGE statement.

    The SQL-standard MERGE doesn't provide for choosing an index, so use of a unique index would need to be conditioned on equality quals against indexed columns in order to provide the behavior being discussed for UPSERT.

    Implementing an extended subset of MERGE support for UPSERT will impact a future implementation of full MERGE support:
    Different concurrency and locking semantics will be needed for a MERGE without equality quals matching a unique index of the target table.
    Users may be very surprised when failure to compare for equality on the columns of a unique index results in slower execution or less graceful interaction with other transactions, such as deadlocks.
    The design for MERGE when the conditions don't allow joining using a unique index has not yet been done. It may require different locking, allow deadlocks or other serialization failures, or allow the same anomalies which can occur with other DML statements, and which will not be possible when the unique index is used.

    If a subquery (rather than a direct table reference) is used for the second relation reference, there is no restriction on what that subquery may join on. Delineating the cases where we must use a dirty snapshot, and where we must use an MVCC snapshot seems very difficult and subtle - Peter Geoghegan [14] [15].

    The ON expression will need to be evaluated to see whether it properly compares to a unique index on the target table. Initially this will need to be done to determine whether the MERGE is allowed at all; later it will determine which sort of plan is allowed. It would be easier to match an index name, provided the index name is known and stable.

    MERGE will probably need to fire before row insert triggers after deciding to insert, since in general it cannot reverse the triggers having been fired - the implementation should probably have decided on insertion by then. In contrast, UPSERT will have to fire before row triggers before deciding to INSERT or UPDATE (by value locking the value extracted from the affected tuple) [16]. With UPSERT, we are deciding to take the alternative path based on the modified tuple. With MERGE, we may prefer not to.

  11. #11
    Membre confirmé
    Homme Profil pro
    nop
    Inscrit en
    mars 2015
    Messages
    436
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : nop
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2015
    Messages : 436
    Points : 620
    Points
    620

    Par défaut

    Citation Envoyé par T`lash Voir le message
    Je l'utilise par exemple dans le cas de l'authentification Active Directory à l'IntraWeb PHP de la société : si l'utilisateur se connecte pour la première fois au système son nom de compte n'existe pas au sein de la base de données, mais tu cherches à obtenir la clé primaire dans la table users. Dans ce cas l'UPSERT insert une ligne et te renvoie l'id de la ligne insérée. Lorsqu'il se connectera pour la seconde fois il te renverra l'id de la ligne existante. Il en va de même pour les groupes auxquels cet utilisateur appartient, qui doivent exister localement pour servir au système de gestion d'accès de l'appli alors que leur création, modification et suppression ne se fait que dans Active Directory.
    donc tu as deux tables d'utilisateurs, c'est répétitif et dangereux sur le point de la sécurité. pourquoi ne pas avoir ajouter à ton intraweb la possibilité d'aller lire l'active directory plutôt que de le redondancer comme ça ? ou de créer une VUE ?



    quand une nouvelle personne arrive dans l'entreprise, vous l'inscrivez dans l'activedirectory, mais pas dans votre intranet ? pourquoi ?

  12. #12
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    371
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 371
    Points : 511
    Points
    511

    Par défaut

    L'intraweb interroge l'Active Directory à chaque connexion d'un utilisateur et récupère les informations de l'utilisateur.
    La base de données Postgres ne contient pas plus d'informations que ce que l'intraweb a besoin pour fonctionner (username, displayname et email).
    Il faut cependant qu'une ligne existe pour chaque utilisateur afin de conserver une intégrité référentielle par rapport aux autres tables de la base.
    Et puisque le but est de conserver une cohérence au sein de tout l'intranet, il est logique que les informations soient conserver par Active Directory puisque c'est cet annuaire qui gère les connexions aux postes de travail.
    Il n'est pas possible de créer, modifier ou supprimer directement un utilisateur ou un groupe en base de données puisque les infos sont lus à chaque connexion depuis l'AD et qu'aucun mot de passe n'est conservé par Postgres.

    Je pense que c'est un cas d'utilisation de l'UPSERT tout ce qu'il y a de plus logique.

  13. #13
    Membre émérite
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 416
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : Mali

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

    Informations forums :
    Inscription : août 2006
    Messages : 1 416
    Points : 2 964
    Points
    2 964
    Billets dans le blog
    6

    Par défaut

    Salut
    Citation Envoyé par MichaelREMY Voir le message
    quelqu'un peut-il me dire dans quel cas fonctionnel, quelle situation (dans la vie réelle, dans une vraie application développée sérieusement), on arrive à un cas où l'on met à jour un enregistrement qui n'est pas existant (qui n'a pas d'id) ?
    ...
    Dans le cas particulier où vos données sont mises à jour à partir d'une source externe (CSV, ...) cette opération est nécessaire.
    Aussi vous avez là une bonne solution pour implémenter une réplication partielle (très semblable au premier cas).
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  14. #14
    Membre confirmé
    Homme Profil pro
    nop
    Inscrit en
    mars 2015
    Messages
    436
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : nop
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2015
    Messages : 436
    Points : 620
    Points
    620

    Par défaut

    Citation Envoyé par alassanediakite Voir le message
    Salut

    Dans le cas particulier où vos données sont mises à jour à partir d'une source externe (CSV, ...) cette opération est nécessaire.
    Aussi vous avez là une bonne solution pour implémenter une réplication partielle (très semblable au premier cas).
    @+
    je suis désolé d'insister, mais je ne vois pas l'utilité.
    c'est très dangereux de mettre à jour des données sans se baser sur son identifiant car risque de doublon..etc.
    par exemple dans mon cas, bcp de gens orthographent mal mon prénom (mettre un K au lieu du H), une fois que je leurs demande de corriger leurs bases, ça veut dire que dans votre cas (import csv), je vais apparaître deux fois dans la base de destination....

    Si vous me répondez alors que ça ne sert qu'à mettre à jour/insérer des données exclusivement chiffrées/numériques , alors là je comprends mieux car le risque est moindre.

  15. #15
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    371
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 371
    Points : 511
    Points
    511

    Par défaut

    De la même manière que dans un échange B2B, il faut avoir une confiance absolu dans sa source.
    Dans mon cas avec Active Directory, il n'y a pas grand risque, surtout que la connexion LDAP est chiffrée.

  16. #16
    Membre émérite
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 416
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : Mali

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

    Informations forums :
    Inscription : août 2006
    Messages : 1 416
    Points : 2 964
    Points
    2 964
    Billets dans le blog
    6

    Par défaut

    Salut
    Citation Envoyé par MichaelREMY Voir le message
    je suis désolé d'insister, mais je ne vois pas l'utilité.
    Peut-être qu'on arrive pas à t'expliquer l'utilité de la chose, mais sache qu'on trouve "MERGE" dans SQL Server, ORACLE, DB2 MySQL, Firebird, PostgreSQL. Ce n'est pas pour rien que tout ces systèmes implémentent la même chose (chacun le faisant un peu en sa manière).
    Dans ton cas(le changement de prénom), je reçoit la ligne (sur le csv) avec CLE et prénom: si la clé existe alors je mets à jour sinon j’insère CLE et prénom.
    Voir ici.
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  17. #17
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    16 955
    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 : 16 955
    Points : 39 360
    Points
    39 360
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par T`lash Voir le message
    Il existe plusieurs raisons à cela, mais la principale est que PostgreSQL se veut un SGBDR collant parfaitement à la norme SQL, ce qui fait qu'ils n'implémentent une instruction que lorsqu'ils sont sûrs de le faire de la bonne manière.
    Oracle et MSSQL utilisent la syntaxe du MERGE pour l'implémentation de l'UPSERT, mais la plupart des SGBDR ont préféré (comme c'est le cas pour PostgreSQL) de choisir un autre mot réservé car la norme SQL-2003 ne définit pas de manière précise le comportement de cette instruction.
    Ne voyez vous pas quelques contradictions dans vos propos :
    1) PG colle à le norme et donc évite le normatif MERGE pour un autre mot !
    2) "la plupart des SGBDR ... ont préférés choisir un autre mot réservé" Ha bon ! Lesquels ?????
    3) "la norme SQL-2003 ne définit pas de manière précise le comportement de cette instruction" Vous croyez sincèrement ce que vous dites ????

    Pour vous punir, je me permets de vous communiquer l'extrait consacré au MERGE dans la norme SQL 2003 (7 pages de description... !)... Au passage il aura juste fallut attendre 12 ans pour voir cela arriver partiellement avec une syntaxe anormative dans PosteGreSQL alors que SQL Server ou Oracle ont cela depuis 10 ans environ...

    Norme SQL 2003-foundation-MERGE statement v.pdf

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

  18. #18
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    371
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 371
    Points : 511
    Points
    511

    Par défaut

    Ne voyez pas une supposition de ma part dans le message que vous avez cité, mais un résumé de la page de discussion du Wiki officiel PostgreSQL que j'ai référencé comme source.
    C'est la justification avancée par l'équipe de PostgreSQL.

  19. #19
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 858
    Points : 6 894
    Points
    6 894

    Par défaut

    Citation Envoyé par Shepard Voir le message
    La commande en PostGreSQL ne s'appelle pas UPSERT mais "ON CONFLICT UPDATE", qui est bien plus explicite je pense :-)
    Mouais un mot/une expression ou une autre, cela ne change pas grand chose.

    Citation Envoyé par Shepard Voir le message
    Le cas d'utilisation est simplement lorsqu'on veut s'assurer que la donnée se trouvera dans la base de données, peu importe si elle était déjà présente ou pas. C'est parfois pratique, mais ça ne reste "que" du sucre syntaxique .
    J'ose expérer que c'est plus que du sucre syntaxique. Le principe d'envoyer en une instruction c'est de permettre au serveur d'optimiser les accès.

    Citation Envoyé par T`lash Voir le message
    L'avantage est de ne pas être obligé de passer par une procédure stockée.
    Pour moi la procédure stockée n'est pas strictement équivalente. Dans la procédure stockée, si l'update échoue il ne verrouille pas la clé. Il peut donc y avoir une attente de libération de verrou entre les deux instructions et donc l'insertion peut échouer. Ce qui ne devrait pas arriverer avec l'instruction "UPSERT".

    Citation Envoyé par MichaelREMY Voir le message
    quelqu'un peut-il me dire dans quel cas fonctionnel, quelle situation (dans la vie réelle, dans une vraie application développée sérieusement), on arrive à un cas où l'on met à jour un enregistrement qui n'est pas existant (qui n'a pas d'id) ?

    ça semble être un moyen de dissimuler/amortir un bug produit dans l'application (qui met à disposition des enregistrements sans ID alors qu'elle ne devrait pas) ?
    Quelle situation de la vie d'un processus autoriserait un tel process : créer un ID quand une identité n'existe pas ... c'est bancal non ?

    Si on met à jour un enregistrement et que l'id n'existe pas, la moindre des choses est de retourner une erreur pour enquêter de la disparition de cet ID (ou du filtrage écran trop strict) plutôt que de recréer une identité.
    Comme indiqué dans la news, c'est ultra-pratique voir indipensable, pour tout ce qui est ETL et de manière générale la synchronsation massive. Faire un update + insert pour chaque enregistrement est beaucoup trop pénalisant en termes de performance.

    Toutes personnes ayant eu à gérer des référentiels externes ou des aggrégations relativement coûteuses à ce genre de problèmatique à traiter. Je pense que beaucoup de projets doivent avoir dans leurs spécifications le fameux "mot clé" : "annule et remplace". C'est ce que permet de faire ce genre d'opérateur dans une optique "sans interruption" de service.

    Citation Envoyé par al1_24 Voir le message
    Il me semble que la commande MERGE apparue dans la norme SQL-2003 opère de manière semblable.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    MERGE INTO ma_table [AS] tgt
    USING ( requete ) [AS] src
    ON ( src.cle = tgt.cle )
    WHEN MATCHED THEN UPDATE SET tgt.col = src.col [, ...]
    WHEN NOT MATCHED THEN INSERT (cle, col [, ...]) VALUES (src.cle, src.col [, ...]);
    Je trouve dommage d'avoir créé une commande spécifique plutôt que se conformer à la norme.
    Pour autant que je me souvienne, la commande "MERGE" ne permet pas vraiment l'insertion d'un tuple donné mais l'injection d'une source de données (table, vue, requête) dans une table (ou une vue updatable). Sous Oracle, je l'ai toujours utilisé pour synchroniser une table "résultante" d'aggrégations.
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

Discussions similaires

  1. Visual Studio 2010 et .NET Framework 4.0 disponible en version Bêta
    Par Jérôme Lambert dans le forum Visual Studio
    Réponses: 32
    Dernier message: 03/09/2014, 22h36
  2. Réponses: 30
    Dernier message: 04/04/2013, 18h08
  3. Réponses: 18
    Dernier message: 10/11/2011, 19h34
  4. Réponses: 0
    Dernier message: 30/09/2011, 17h41
  5. Réponses: 0
    Dernier message: 05/04/2011, 11h32

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