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

    Par défaut

    Citation Envoyé par zinzineti Voir le message
    Bonjour François,
    Tes interventions sur ce forum sont à 99.9999 % de très bonne qualité. Qualité sur le fond et aussi sur la forme et je voudrais ici te remercier pour le temps que tu consacres à partager tes connaissances et à nous éclairer sur la modélisation et l'implémentation des bases de données relationnelles.
    Pour revenir à mon post, je précise que l'objectif c'est la possibilité de personnaliser les messages d'erreurs pour les contraintes CHECK en cas de violation. Je reconnais que le message renvoyé par MS SQL en cas de violation de contrainte est suffisant pour corriger les problèmes pour une personne ayant une petite expérience en SQL mais pas pour quelqu'un qui est plus orienté métier/fonctionnel. Ce qui me gène c'est l'impossibilité d'ajouter une information métier/fonctionnelle/complémentaire en cas de violation de contrainte. Pour une application client-Serveur, on peut ajouter cette information métier/fonctionnelle/complémentaire côté client.
    C'est sans aucun doute votre manque d'imagination ou d'expérience...

    1) n'oubliez pas que normalement vous devriez utiliser des vues et de proc stoc pour developper vos applications (modèle de données externe) et non en accès directe aux tables (hérésie !)
    2) dans ce cas implémenter des triggers INSTEAD OF sur les vues
    3) au final, créer une table des messages personnalisés et dans le CATCH de vos bloc TRY/CATCH de vos procédures, récupérer le message d'erreur (@@MESSAGE) et le substituer à un message perso.

    Votre approche par trigger est douvblement mauvaise :
    1) le trigger SQL s'exécute APRES. Il est déjà trop tard pour certaines vérifications et cela coute plus cher qu'une contrainte qui s'exécute AVANT.
    2) les trigger ont ce qu'il y a de plus couteux. Vous aurez donc de mauvaises perf et donc une montée en charge bien moindre

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

  2. #102
    Membre éprouvé

    Profil pro
    Inscrit en
    juillet 2006
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : juillet 2006
    Messages : 1 448
    Points : 1 199
    Points
    1 199

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Totalement inutile.

    Une adresse IP est un entier 32 bits qui par convention est présenté sous forme de 4 entiers d'un octet.
    "De mon temps on n'avait pas besoin de tout ça. Une patate et un verre d'eau à la naissance et il en restait encore quelque chose à votre décès." (un vielle ermite)

    Vous confondez accessoire et inutile.
    Je vous rappelle que toute donnée peut être stockée en varbinary pourtant je suis convaincu que vous ne trouver pas le type entier inutile.

    Citation Envoyé par SQLpro
    1) le trigger SQL s'exécute APRES. Il est déjà trop tard pour certaines vérifications et cela coute plus cher qu'une contrainte qui s'exécute AVANT.
    Où est-ce que vous situé l'excécutin d'un trigger instead of dans le workflow d'une opération dml ?
    Most Valued Pas mvp

  3. #103
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    novembre 2004
    Messages
    1 738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Gironde (Aquitaine)

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

    Informations forums :
    Inscription : novembre 2004
    Messages : 1 738
    Points : 3 012
    Points
    3 012

    Par défaut

    Je vous rappelle que toute donnée peut être stockée en varbinary pourtant je suis convaincu que vous ne trouver pas le type entier inutile.
    Entendez par là que la notion d'IP n'est qu'une PRESENTATION d'un entier 32 BIT... En théorie ce n'est donc pas au SGBD de prévoir cette représentation
    Où est-ce que vous situé l'excécutin d'un trigger instead of dans le workflow d'une opération dml ?
    SQL PRO voulait; nul doute n'est possible; parler des traditionnels TRIGGER FOR et non INSTEAD OF...
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

  4. #104
    Membre émérite

    Homme Profil pro
    Chargé de Développement et d'Analyse de données
    Inscrit en
    mars 2010
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chargé de Développement et d'Analyse de données
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : mars 2010
    Messages : 1 278
    Points : 2 795
    Points
    2 795

    Par défaut Modification directe des tables via une vue SQL ?!

    Bonjour à toutes et à tous !
    Quelqu'un peut m'expliquer pourquoi les éditeurs de SGBDR ont du mal à permettre via une vue la modification directe des tables sous-jacentes la vue SQL ?
    Je m'explique :
    => Sous SQL Server
    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
    CREATE TABLE T_PERSONNE (id int, nom varchar(50), prenom varchar(50),email varchar(50))
     
    CREATE VIEW V_PERSONNE (nom,prenom,email)
    AS
    SELECT nom,prenom,email FROM T_PERSONNE
    UNION
    SELECT null,null,null
     
    INSERT INTO V_PERSONNE VALUES ('ZINZINDOHOUE','Etienne','zinzineti@yahoo.fr')
     
    --> Résultat
    /*
    Msg 4406, Level 16, State 1, Line 1
    Update or insert of view or function 'V_PERSONNE' failed because it contains a derived or constant field.
    */
    Le BOL MS SQL SERVER justifie clairement pourquoi je ne peux pas faire de modification sur ma vue :
    Pour modifier les données d'une table sous-jacente, vous pouvez utiliser une vue sous réserve que les conditions suivantes soient vraies :
    * Toute modification, y compris celles via les instructions UPDATE, INSERT et DELETE, doivent faire référence aux colonnes d'une seule et même table de base.
    * Les colonnes étant modifiées dans la vue doivent faire référence directement aux données sous-jacentes se trouvant dans les colonnes des tables. Les colonnes ne peuvent être dérivées de quelque autre façon, telle que par :
    Une fonction d'agrégation : (AVG, COUNT, SUM, MIN, MAX, GROUPING, STDEV, STDEVP, VAR et VARP) ;
    un calcul, car la colonne ne peut être calculée à partir d'une expression utilisant d'autres colonnes ; de même, les colonnes formées par le biais des opérateurs UNION, UNION ALL, CROSSJOIN, EXCEPT et INTERSECT équivalent à une somme de calculs et ne peuvent donc pas être mises à jour
    et MS SQL SERVER propose une porte de sortie :

    Si les restrictions précédentes vous empêchent de modifier des données directement à travers une vue, voici quelques options à considérer pour vous aider :
    Déclencheurs INSTEAD OF
    Les déclencheurs INSTEAD OF peuvent être créés sur une vue pour que celle-ci puisse être mise à jour. ....
    Bref MS SQL SERVER impose de passer par un trigger INSTEAD OF ... pour modifier les tables sous-jacentes d'une vue SQL. D'où ma question pourquoi MS SERVER complique la mise des tables d'une vue et impose de passer par un trigger INSTEAD OF ?

    => Sous ORACLE

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    CREATE VIEW V_PERSONNE (nom,prenom,email) AS  SELECT nom,prenom,email FROM T_PERSONNE UNION SELECT null,null,null FROM DUAL;
    INSERT INTO V_PERSONNE VALUES ('ZINZINDOHOUE','Etienne','zinzineti@yahoo.fr');
     
    --> Résultat
    /*
    ERREUR à la ligne 1 :
    ORA-01732: les manipulations de données sont interdites sur cette vue
    */
    Pareil ! impossible de mettre à jour ma table !

    => Sous PostGreSQL
    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
     
    create view V_PERSONNE (nom,prenom,email)
    AS
    SELECT nom,prenom,email FROM T_PERSONNE
    UNION
    SELECT null,null,null
     
    INSERT INTO V_PERSONNE VALUES ('ZINZINDOHOUE','Etienne','zinzineti@yahoo.fr')
     
    --> Résultat
    /*
    ERREUR: ne peut pas insérer dans la vue « v_personne »
    État SQL :55000
    Astuce : Vous avez besoin d'une règle ON INSERT DO INSTEAD sans condition ou d'un trigger INSTEAD OF INSERT.
    */
    idem PostGreSQL suggère aussi l'utilisation d'un trigger !

    N'est ce pas un des inconvénients de travailler avec des vues SQL ?
    Etienne ZINZINDOHOUE
    Billets-Articles

  5. #105
    Membre émérite
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 415
    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 415
    Points : 2 961
    Points
    2 961
    Billets dans le blog
    6

    Par défaut

    Salut
    Je trouve mieux, qu'il faut des vues pour "lecture unique", des vues pour "lecture et écriture" et de procédures stockées pour mise à jour complexe. Les vues de lectures sont souvent très complexes et vouloir agir directement sur les données me semble illogique.
    Par contre je digère mal le fait que les vues de PostgreSQL sont systématiquement en lecture seule. Un produit aussi performant ne doit pas avoir de telle limitation.
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  6. #106
    Membre émérite

    Homme Profil pro
    Chargé de Développement et d'Analyse de données
    Inscrit en
    mars 2010
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chargé de Développement et d'Analyse de données
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : mars 2010
    Messages : 1 278
    Points : 2 795
    Points
    2 795

    Par défaut

    J'ai un peu du mal à comprendre.
    Peux-tu montrer un exemple pour chaque cas ? :
    --> vue pour "lecture unique"
    --> vue pour "lecture et écriture"

    Merci d'avance
    Etienne ZINZINDOHOUE
    Billets-Articles

  7. #107
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 789
    Points
    18 789
    Billets dans le blog
    15

    Par défaut

    Bonjour,


    Citation Envoyé par zinzineti Voir le message
    Quelqu'un peut m'expliquer pourquoi les éditeurs de SGBDR ont du mal à permettre via une vue la modification directe des tables sous-jacentes la vue SQL ?
    Voui, Etienne !

    L’explication est fournie par Chris Date dans An Introduction to Database Systems, Eighth Edition (Addison Wesley), page 305, je cite et traduis :
    La mise à jour des vues est un sujet d’ordre sémantique et non pas syntaxique, c'est-à-dire que cela ne dépend pas d’un quelconque choix syntaxique pour formuler une expression. Par exemple, les deux formulations ci-dessous sont sémantiquement équivalentes :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    VAR VIEW V
        S WHERE STATUS > 25 OR CITY = 'Paris' ;
     
    VAR VIEW V
        (S WHERE STATUS > 25) UNION (CITY = 'Paris') ;
    Bien sûr, soit ces deux vues sont toutes deux mise à jour « mettables », soit aucune (en fait, ici elles le sont toutes les deux). Par contraste, la norme SQL et la plupart des produits SQL adoptent la position ad hoc selon laquelle la première des deux vues peut être mise à jour, mais pas la deuxième.

    Comme dit Date, si on les suit, les règles impénétrables énoncées par la norme constituent une barrière infranchissable pour le développement de la mise à jour des vues en général...

    Pour vérification, je fournis l’équivalent SQL des vues proposées par Chris Date.


    Table S des fournisseurs :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    CREATE TABLE S
    (
            FourNo        CHAR(4)         NOT NULL
          , FourNom       VARCHAR(48)     NOT NULL
          , Statut        INT             NOT NULL
          , Ville         VARCHAR(48)     NOT NULL
        , CONSTRAINT FOUR_PK PRIMARY KEY (FourNo) 
    ) ;

    Jeu d’essai :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    INSERT INTO S (FourNo, FourNom, Statut, Ville) VALUES ('F001', 'Cézigue', 10, 'Lille') ;
    INSERT INTO S (FourNo, FourNom, Statut, Ville) VALUES ('F002', 'Paulo', 30, 'Nantes') ;
    INSERT INTO S (FourNo, FourNom, Statut, Ville) VALUES ('F003', 'Loulou', 26, 'Nancy') ;
    INSERT INTO S (FourNo, FourNom, Statut, Ville) VALUES ('F007', 'Bond', 20, 'Paris') ;
     
    SELECT FourNo, FourNom, Statut, Ville from S
     ;

    Vue de type UNION :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    CREATE VIEW V_UNION (FourNo, FourNom, Statut, Ville) AS
    SELECT FourNo, FourNom, Statut, Ville
    FROM   S
    WHERE  Statut > 25
    UNION
    SELECT FourNo, FourNom, Statut, Ville
    FROM   S
    WHERE  Ville = 'Paris'
    ;

    Un insert :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    INSERT INTO  V_UNION (FourNo, FourNom, Statut, Ville) VALUES ('F307', 'Etienne', 40, 'Rome') ;
    => Boum ! Avec un message sibyllin, sans rapport :

    Citation Envoyé par SQL Server

    Msg 4406, Level 16, State 1, Line 7
    Impossible de mettre à jour ou d'insérer la vue ou la fonction 'V_UNION' car elle contient un champ dérivé ou constant.
    Si au lieu de l’opérateur UNION on utilise le connecteur logique OR :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    CREATE VIEW V_OU (FourNo, FourNom, Statut, Ville) AS
    SELECT FourNo, FourNom, Statut, Ville
    FROM   S
    WHERE  Statut > 25 OR Ville = 'Paris' ;
    GO 
     
    INSERT INTO  V_OU (FourNo, FourNom, Statut, Ville) VALUES ('F307', 'Etienne', 40, 'Rome') ;
    Alors tout baigne.


    Accessoirement, pour montrer l’édifiante cohérence des messages fournis par MS SQL Server, remplaçons l’UNION par une INTERSECTION :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    CREATE VIEW V_INTERSECT (FourNo, FourNom, Statut, Ville) AS
    SELECT FourNo, FourNom, Statut, Ville
    FROM   S
    WHERE  Statut > 25
    INTERSECT
    SELECT FourNo, FourNom, Statut, Ville
    FROM   S
    WHERE  Ville = 'Paris'
    ;
    GO
    INSERT INTO  V_INTERSECT (FourNo, FourNom, Statut, Ville) VALUES ('F308', 'Charles', 10, 'Madrid') ;
    =>
    Citation Envoyé par SQL Server

    Msg 4403, Level 16, State 1, Line 11
    Impossible de mettre à jour la vue ou la fonction "V_INTERSECT" car elle contient des agrégats ou une clause DISTINCT.
    Vu l'étroite relation qu'entretiennent les opérateurs UNION et INTERSECTION, j'en conclus l'équivalence des formulations, mais qui n'ont aucun rapport sémantique avec nos opérateurs... :

    "Impossible de mettre à jour la vue car elle contient un champ dérivé ou constant" et "Impossible de mettre à jour la vue car elle contient des agrégats ou une clause DISTINCT".
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  8. #108
    Membre émérite
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 415
    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 415
    Points : 2 961
    Points
    2 961
    Billets dans le blog
    6

    Par défaut

    Salut
    ZINEZINETI: (bien que je trouve votre question trop proche des débutants, l'étude des bibliothèques d'accès aux données le prouve à suffisance!)
    -->pour vue en lecture seule: une vue pour tracer l'ensemble des opérations d'un client dans une banque à une période donnée; ou encore une vue pour son tableau de bord (compte courant, compte d'épargne, encours de prêt)
    -->pour une vue en lecture écriture: dans une table "etudiant" (que vous optez pour une table obèse ou une table principale avec des tables connexes) il faut une vue avec le minimum de champs (colonne par respect pour les orthodoxes) obligatoires (NON NULL) pour enregistrer rapidement (à l'ouverture de l'année) les nouveaux étudiants.
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  9. #109
    Membre émérite

    Homme Profil pro
    Chargé de Développement et d'Analyse de données
    Inscrit en
    mars 2010
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chargé de Développement et d'Analyse de données
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : mars 2010
    Messages : 1 278
    Points : 2 795
    Points
    2 795

    Par défaut

    Citation Envoyé par fsmrel Voir le message
    "Impossible de mettre à jour la vue car elle contient un champ dérivé ou constant" et "Impossible de mettre à jour la vue car elle contient des agrégats ou une clause DISTINCT".
    Bonjour François
    Oui ce message d'erreur est vraiment rigolo
    "Impossible de mettre à jour la vue car elle contient un champ dérivé ou constant"
    Champ dérivé ??? comme si une vue peut ne pas dériver d'une table ! quelle confusion !
    La gestion des messages d'erreurs n'est pas chose facile, mais bon...
    Je souligne au travers de ton développement que :
    1) MS SQL Server et les autres éditeurs de DBMS ne peuvent pas à mettre à jour une vue si elle contient les opérateurs UNION, INTERSECT, EXCEPT , ....

    2) MS SQL Server et les autres éditeurs de DBMS sont incapables de faire une traduction logique d'une expression SQL contenant les opérateurs UNION, INTERSECT, EXCEPT,... afin de permettre la mise à jour d'une vue. Et ils se contentent simplement de dire que si la syntaxe contient les opérateurs UNION, INTERSECT, EXCEPT,.. impossible de mettre à jour la vue ! C'est ce qu'on appelle "être partisan de moindre effort" ! et pourtant SQL est un langage, et dans toute langue il n'y a pas une seule façon de s'exprimer ! dans la langue française par exemple la notion de synonymie existe ?! ajouter - additionner - sommer - .... désigne la même opération !?

    3) MS SQL Server et les autres éditeurs de DBMS ne respectent pas le principe d’interchangeabilité (The principe of Interchangeability) évoqué par C.J. DATE c-a-d qu'il ne doit pas y avoir logiquement de distinction entre "Table" et "Vue"

    Jusque là nous n'avons pas encore abordé l'autre "règle d'or" des éditeurs de DBMS et leurs prophètes qui mettent tout en oeuvre pour graver dans les esprits que : " les vues multitables (avec des JOINs) ne peuvent être modifiées (INSERT, UPDATE, DELETE) directement et qu'il faut utiliser des triggers INSTEAD OF "

    Comme le suggère C.J DATE faisons du lobbing auprès des éditeurs DBMS pour qu'ils lèvent ces limitations !

    Si un jour ces limitations majeures sur les vues sont levées alors on aura plus de plaisir à travailler avec les vues ...

    A+
    Etienne ZINZINDOHOUE
    Billets-Articles

  10. #110
    Membre éprouvé

    Profil pro
    Inscrit en
    juillet 2006
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : juillet 2006
    Messages : 1 448
    Points : 1 199
    Points
    1 199

    Par défaut

    Après avoir cherché je ne trouve pas de commande pour effacer/vider la liste des messages qui apparait dans le Management Studio.
    Ça devrait être rajouter si ça n'existe pas et ça doit être plus facile à trouver si cela existe.
    Most Valued Pas mvp

  11. #111
    Membre émérite
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 415
    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 415
    Points : 2 961
    Points
    2 961
    Billets dans le blog
    6

    Par défaut

    Salut
    En avant pour perdre des points
    ZINEZINETI:
    Soit
    la table facture(idfacture, datefacture, typefacture::=vente| achat),
    la table reglement(idfacture, idreglement, datereglement, montantreglement)
    et la requête factureJreglement(SELECT facture.idfacture, facture.datefacture, facture.typefacture, reglement.idreglement, reglement.datereglement, reglement.montantreglement).
    Si le SGBD autorise la modification et la suppression, que sera le comportement du SGBD si je supprime une ligne...
    -->suppression de la facture sans compter s'il y a une intégrité référentielle
    -->suppression du règlement...
    que sera le comportement de la fenêtre (formulaire)
    -->rafraichissement des données
    -->laisser les choses et après, provoquer des erreurs de cohérence de données?
    Avec tout le respect que je te dois, ton souhait est pratiquement impossible (bien que impossible et informatique ne font pas bon ménage!!!). Les autres concepts des bases de données sont là pour ça!!!
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  12. #112
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 789
    Points
    18 789
    Billets dans le blog
    15

    Par défaut

    Bonsoir,


    Citation Envoyé par alassanediakite Voir le message
    ton souhait est pratiquement impossible
    A quel souhait de zinzineti faites-vous allusion ? Que cherchez-vous à démontrer ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  13. #113
    Membre émérite
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 415
    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 415
    Points : 2 961
    Points
    2 961
    Billets dans le blog
    6

    Par défaut

    Salut fsmrel (s'il y a question de me tirer les oreilles, allez-y doucement)
    La réponse à votre demande...
    Citation Envoyé par zinzineti Voir le message
    3) MS SQL Server et les autres éditeurs de DBMS ne respectent pas le principe d’interchangeabilité (The principe of Interchangeability) évoqué par C.J. DATE c-a-d qu'il ne doit pas y avoir logiquement de distinction entre "Table" et "Vue"

    Jusque là nous n'avons pas encore abordé l'autre "règle d'or" des éditeurs de DBMS et leurs prophètes qui mettent tout en oeuvre pour graver dans les esprits que : " les vues multitables (avec des JOINs) ne peuvent être modifiées (INSERT, UPDATE, DELETE) directement et qu'il faut utiliser des triggers INSTEAD OF "

    Comme le suggère C.J DATE faisons du lobbing auprès des éditeurs DBMS pour qu'ils lèvent ces limitations !

    Si un jour ces limitations majeures sur les vues sont levées alors on aura plus de plaisir à travailler avec les vues ...

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

  14. #114
    Membre émérite

    Homme Profil pro
    Chargé de Développement et d'Analyse de données
    Inscrit en
    mars 2010
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chargé de Développement et d'Analyse de données
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : mars 2010
    Messages : 1 278
    Points : 2 795
    Points
    2 795

    Par défaut

    Bonjour Alassane,
    Tu peux faire un DELETE avec garantie de la qualité des données en utilisant le trigger INSTEAD OF DELETE pour le cas que tu as présenté.
    Mais ce que je souhaite c'est la possibilité de faire des modifications (INSERT, UPDATE,DELETE) avec garantie de la qualité des données sans passer par des triggers INSTEAD OF.
    J'ai montré sur mon blog des exemples d'utilisation de triggers INSTEAD OF :
    --> INSTEAD OF INSERT (insert via une vue)
    --> INSTEAD OF UPDATE (update via une vue)
    --> Tu peux en guise d'entrainement essayer de faire le trigger INSTEAD OF DELETE sur ta vue
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    V_facturereglement (facture.idfacture, facture.datefacture, facture.typefacture, reglement.idreglement, reglement.datereglement, reglement.montantreglement)
    normalement tu dois obtenir le résultat que tu souhaites.
    Tu peux nous montrer après comment tu as écrit ton trigger INSTEAD OF DELETE.
    D'accord ? Je compte sur toi !
    A+
    Etienne ZINZINDOHOUE
    Billets-Articles

  15. #115
    Membre émérite

    Homme Profil pro
    Chargé de Développement et d'Analyse de données
    Inscrit en
    mars 2010
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chargé de Développement et d'Analyse de données
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : mars 2010
    Messages : 1 278
    Points : 2 795
    Points
    2 795

    Par défaut VIEW et CONTRAINTES :

    Bonjour à tous et à toutes !
    En relisant hier le livre SQL and Relational Theory sous titré How to Write Accurate SQL Code (C.J. Date) un exemple de violation du principe de l'interchangeabilité (The principle of Interchangeability) a attiré mon attention : la possibilité de poser des constraintes sur une vue SQL. On peut penser que ça peut être redondant/conflictuel de poser des contraintes sur une vue. Eh ben non !
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
     
    CREATE TABLE S
    (
            FourNo        CHAR(4)         NOT NULL
          , FourNom       VARCHAR(48)     NOT NULL
          , Statut        INT             NOT NULL
          , Ville         VARCHAR(48)     NOT NULL
        , CONSTRAINT FOUR_PK PRIMARY KEY (FourNo) 
    ) ;
     
    INSERT INTO S (FourNo, FourNom, Statut, Ville) VALUES ('F001', 'Cézigue', 10, 'Lille') ;
    INSERT INTO S (FourNo, FourNom, Statut, Ville) VALUES ('F002', 'Paulo', 30, 'Nantes') ;
    INSERT INTO S (FourNo, FourNom, Statut, Ville) VALUES ('F003', 'Loulou', 26, 'Nancy') ;
    INSERT INTO S (FourNo, FourNom, Statut, Ville) VALUES ('F007', 'Bond', 20, 'Paris') ;
    Créons une vue des fournisseurs de LILLE

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    CREATE VIEW V_LS AS 
     SELECT * FROM S WHERE Ville ='Lille'
     
     SELECT * FROM V_LS
     --> Résultat
     F001	 Cézigue	10	   Lille
    La vue V_LS est créée pour renseigner les fournisseurs de la ville de Lille.
    Tentons une insertion via cette vue

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    INSERT INTO V_LS (FourNo, FourNom, Statut, Ville) VALUES ('F009','FouFouAfrica',50,'Abomey');
    --> Résultat : Insertion effectuée avec succès !
    Cette insertion a violé le fait que la vue V_LS concerne UNIQUEMENT les fournisseurs de Lille ! Mais là nous venons d'utiliser cette vue pour insérer un fournisseur de la ville d'Abomey ! Il manque donc une contrainte sur cette vue. Puisque SQL Server ne respecte le principe de l'interchangeabilité
    (The principle of Interchangeability) je ne peux donc pas poser des contraintes directement sur la vue ! Néanmoins MS SQL Server et ORACLE ont implémenté l'option "WITH CHECK OPTION" qui règle ce problème. Ce n'est pas encore le cas pour PostGreSQL !

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
     
     DROP VIEW V_LS
     --> Vue des fournisseurs de LILLE
     CREATE VIEW V_LS AS 
     SELECT * FROM S WHERE Ville ='Lille'
     WITH CHECK OPTION;
     
     INSERT INTO V_LS (FourNo, FourNom, Statut, Ville) VALUES ('F006','FouFouAfrica2',52,'Abomey'); 
     --> Résultat
     Msg 550, Level 16, State 1, Line 1
    The attempted insert or update failed because the target view either specifies WITH CHECK OPTION or spans a view that specifies WITH CHECK OPTION and one or more rows resulting from the operation did not qualify under the CHECK OPTION constraint.
    The statement has been terminated.
    Un effort de réglage de message d'erreur reste à faire côté MS SQL Server
    Le message d'erreur renvoyé par ORACLE est beaucoup plus clair :
    ERREUR à la ligne 1 :
    ORA-01402: vue WITH CHECK OPTION - violation de clause WHERE
    A+
    Etienne ZINZINDOHOUE
    Billets-Articles

  16. #116
    Membre émérite
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 415
    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 415
    Points : 2 961
    Points
    2 961
    Billets dans le blog
    6

    Par défaut

    Salut
    Étienne, n'essaye pas de tourner le sens du problème.
    Puis-que tu trouve que les SGBD doivent permettre la suppression, l'ajout et la modification sans passer par un trigger, alors je te demande de décrire le comportement du SGBD et des application accédant aux données, face aux cas que j'ai présentés sans trigger.
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  17. #117
    Membre émérite

    Homme Profil pro
    Chargé de Développement et d'Analyse de données
    Inscrit en
    mars 2010
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chargé de Développement et d'Analyse de données
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : mars 2010
    Messages : 1 278
    Points : 2 795
    Points
    2 795

    Par défaut

    Citation Envoyé par alassanediakite Voir le message
    Salut
    Étienne, n'essaye pas de tourner le sens du problème.
    Puis-que tu trouve que les SGBD doivent permettre la suppression, l'ajout et la modification sans passer par un trigger, alors je te demande de décrire le comportement du SGBD et des application accédant aux données, face aux cas que j'ai présentés sans trigger.
    @+
    Alassane,
    Je pense qu'il y a des malentendus ou des maldits ou des malcompris ...
    Pour résumé ma réflexion, je peux dire que je souhaite que les éditeurs de DBMS implémentent la possibilité de modifier (INSERT,UPDATE,DELETE) directement une vue SQL multitables avec garantie de la qualité des données sans passer par des triggers INSTEAD OF.

    A+
    Etienne ZINZINDOHOUE
    Billets-Articles

  18. #118
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    août 2005
    Messages
    4 983
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : août 2005
    Messages : 4 983
    Points : 11 471
    Points
    11 471

    Par défaut

    Je vais me faire un peu l'avocat du diable mais bon ca alimentera un peu le débat

    "Impossible de mettre à jour la vue car elle contient un champ dérivé ou constant"
    Champ dérivé ??? comme si une vue peut ne pas dériver d'une table ! quelle confusion !
    Ne nous emballons pas ... champ ou disons plus colonne dérivée n'a rien à avoir avec une dérivation de table par une vue. On ne parle pas vraiment de la même chose.

    Accessoirement, pour montrer l’édifiante cohérence des messages fournis par MS SQL Server, remplaçons l’UNION par une INTERSECTION :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    SELECT FourNo, FourNom, Statut, Ville
    FROM   S
    --WHERE  Statut > 25
    INTERSECT
    SELECT FourNo, FourNom, Statut, Ville
    FROM   S
    --WHERE  Ville = 'Paris'
    ;
    GO
    Est-ce que cette requête ne serait pas équivalent à :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    SELECT DISTINCT S.FourNo, S.FourNom, S.Statut, S.Ville
    FROM   S
    INNER JOIN S AS S2
     ON S.FourNo = S2.FourNo
    auquel cas le message d'erreur suivant ne serait pas si dénué de ce sens. La requête étant là juste pour souligner le fait qu'un INTERSECT conduira forcément à une opération DISTINCT.

    Même chose pour :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    CREATE VIEW V_UNION (FourNo, FourNom, Statut, Ville) AS
    SELECT FourNo, FourNom, Statut, Ville
    FROM   S
    WHERE  Statut > 25
    UNION
    SELECT FourNo, FourNom, Statut, Ville
    FROM   S
    WHERE  Ville = 'Paris'
    ;
    => Boum ! Avec un message sibyllin, sans rapport :
    Pourtant en regardant le plan d'exécution on peut voir que le fait de réaliser un UNION va produire la création d'une table virtuelle qui va concaténer les résultats. On n'a pas un mappage direct des colonnes de la vue avec les tables sous jascentes d'où le message d'erreur qui pourrait venir de la ...


    --> Résultat : Insertion effectuée avec succès !
    Cette insertion a violé le fait que la vue V_LS concerne UNIQUEMENT les fournisseurs de Lille ! Mais là nous venons d'utiliser cette vue pour insérer un fournisseur de la ville d'Abomey ! Il manque donc une contrainte sur cette vue. Puisque SQL Server ne respecte le principe de l'interchangeabilité
    Je ne vois pas ce que le principe d'interchangeabilité vient faire ici. Les contraintes sur les vues font parti de la norme et elles sont justement destinées à cela à moins de me tromper quelque part ...

    Msg 550, Level 16, State 1, Line 1
    The attempted INSERT OR UPDATE failed because the target VIEW either specifies WITH CHECK OPTION OR spans a VIEW that specifies WITH CHECK OPTION AND one OR more rows resulting FROM the operation did NOT qualify under the CHECK OPTION constraint.
    The statement has been terminated

    Un effort de réglage de message d'erreur reste à faire côté MS SQL Server
    .
    Pourtant je le trouve pourtant clair. Je pense que je peux passer outre la traduction du message


    On parle de principe d'interchangeabilité et effectivement aucun SGBD ne répond vraiment à cela. On a bien entendu des artifices qui permettent de faire cela avec les fameux triggers INSTEAD OF.

    Je peux comprendre les éditeurs sur le fait que pour certains cas implémenter une logique de mise à jour native au moteur peut être extraimement complexe. Tu as pris l'exemple des contraites check qui est un exemple plutôt simple dirons nous. Si on regarde derrière le capot avec une visualisation du plan d'éxecution on peut remarquer ceci :

    1- Creation d'une ligne "dummy" qui possède la valeur que nous voulons insérer
    2. insérer cette ligne dans la table ou index
    3. Vérifier que la valeur respecte notre contrainte
    4. Valider si ok sinon il faut rollbacker la transaction

    Rien que pour une pauvre contrainte CHECK on a déjà un certain nombre d'opérations à effectuer alors imaginons cela pour des requêtes plus complexes ... On parle d'interchangeabilité certes mais en pratique nous sommes encore loin de la théorie

    ++

  19. #119
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 789
    Points
    18 789
    Billets dans le blog
    15

    Par défaut

    Bonjour,


    Citation Envoyé par alassanediakite Voir le message

    facture (idfacture, datefacture, typefacture::=vente| achat ;
    reglement (idfacture, idreglement, datereglement, montantreglement).
    Renommons facture en A et reglement en B. On a le prédicat, appelons-le PA :
    La facture IdFacture est datée du DateFacture, elle est du type TypeFacture.
    Où IdFacture, DateFacture et TypeFacture sont les paramètres du prédicat.

    De même, on a le prédicat, appelons-le PB :
    Le règlement IdReglement de la facture IdFacture est daté du DateReglement et son montant est MontantReglement.

    Considérons la jointure J qui fait l’objet de votre SELECT (je suppose que vous sous-entendez que votre jointure est une jointure naturelle) :

    facture.idfacture, facture.datefacture, facture.typefacture, reglement.idreglement, reglement.datereglement, reglement.montantreglement

    Son prédicat PJ est le suivant :
    PA (a) AND PB (b)

    Où pour un tuple donné j du produit, a est la part de j qui revient à A (disons par projection) et b la part qui revient à B.

    Venons-en aux mises à jour des vues. Les règles générales valant pour la jointure en sont les suivantes cf. Chris Date dans An Introduction to Database Systems, Eighth Edition (Addison Wesley), page 315 :

    INSERT :
    Le nouveau tuple j doit satisfaire PJ. Si la part de j qui revient à A n’apparaît pas dans A, elle est insérée dans A. Si la part de j qui revient à B n’apparaît pas dans B, elle est insérée dans B.

    DELETE :
    la part A du tuple à supprimer est supprimée dans A et la part B du tuple à supprimer est supprimée dans B.

    UPDATE :
    Le tuple à mettre à jour doit être tel que la version mise à jour doit satisfaire PJ. La part qui revient à A est supprimée de A (sans déclenchement automatique d’actions quelconques ni de contrôles de prédicats), et la part qui revient à B est supprimée de B (sans déclenchement d’actions quelconques ni de contrôles de prédicats). Ensuite, si la part qui revient à A n’apparaît pas dans A, elle est insérée dans A ; si la part qui revient à B n’apparaît pas dans B, elle est insérée dans B.

    Chris Date étudie ensuite de façon systématique et détaillée les conditions dans lesquelles une mise à jour d’une vue « de jointure » est acceptée ou doit être rejetée, selon que A et B entretiennent des relations de type un-à-un, un-à-plusieurs ou plusieurs à plusieurs. Je vous invite à le suivre dans son étude (aux pages 315-318 de son ouvrage).
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  20. #120
    Membre émérite

    Homme Profil pro
    Chargé de Développement et d'Analyse de données
    Inscrit en
    mars 2010
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chargé de Développement et d'Analyse de données
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : mars 2010
    Messages : 1 278
    Points : 2 795
    Points
    2 795

    Par défaut

    Bonjour David,
    Merci pour l'intérêt que tu portes à cette discussion
    Citation Envoyé par mikedavem Voir le message
    Je vais me faire un peu l'avocat du diable mais bon ca alimentera un peu le débat
    être évangéliste c'est mieux qu'être avocat du diable non ? je rigole
    Bon sérieux je vais argumenter une peu :
    Citation Envoyé par mikedavem Voir le message
    Ne nous emballons pas ... champ ou disons plus colonne dérivée n'a rien à avoir avec une dérivation de table par une vue. On ne parle pas vraiment de la même chose.
    Oui tu as raison, mais même en remplaçant champ par colonne dans ce message, tu comprends quelque chose ?

    Citation Envoyé par mikedavem Voir le message
    Je ne vois pas ce que le principe d'interchangeabilité vient faire ici. Les contraintes sur les vues font parti de la norme et elles sont justement destinées à cela à moins de me tromper quelque part ...
    Là je voudrais évoqué l'impossibilité de poser directement et finement pour chaque colonne de la vue la contrainte qu'on veut comme on peut le faire lors de la création d'une table. C-a-d quelque qui ressemblerait à
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
     CREATE VIEW V_LS AS
     SELECT * FROM  S 
     WITH CONSTRAINT CHCK_CITY CHECK (CITY = 'Lille')
    au lieu d’enrober toutes les contraintes dans l'option WITH CHECK OPTION

    Citation Envoyé par mikedavem Voir le message
    Pourtant je le trouve pourtant clair. Je pense que je peux passer outre la traduction du message

    Ah les traductions... quelqu'un disait que les traductions c'est comme une femme. Plus elle est belle plus elle est infidèle et plus elle est moche plus elle est infidèle...

    Citation Envoyé par mikedavem Voir le message
    On parle de principe d'interchangeabilité et effectivement aucun SGBD ne répond vraiment à cela. On a bien entendu des artifices qui permettent de faire cela avec les fameux triggers INSTEAD OF.

    Je peux comprendre les éditeurs sur le fait que pour certains cas implémenter une logique de mise à jour native au moteur peut être extraimement complexe. Tu as pris l'exemple des contraites check qui est un exemple plutôt simple dirons nous. Si on regarde derrière le capot avec une visualisation du plan d'éxecution on peut remarquer ceci :

    1- Creation d'une ligne "dummy" qui possède la valeur que nous voulons insérer
    2. insérer cette ligne dans la table ou index
    3. Vérifier que la valeur respecte notre contrainte
    4. Valider si ok sinon il faut rollbacker la transaction
    Je suis à 100 % d'accord avec cette analyse

    Citation Envoyé par mikedavem Voir le message
    Rien que pour une pauvre contrainte CHECK on a déjà un certain nombre d'opérations à effectuer alors imaginons cela pour des requêtes plus complexes ... On parle d'interchangeabilité certes mais en pratique nous sommes encore loin de la théorie
    ++
    La théorie ?! là je ne suis pas d'accord.
    C'est plutôt sur ces sujets que doivent se pencher les éditeurs de DBMS. Et ce serait une vraie avancée de se pencher sur les vrais problèmes. Au lieu de ça qu'est ce qu'on constate : la course aux nouvelles versions ! Quelques nouvelles fonctionnalités emballées sur d'anciens bugs non corrigés, le tout embarqué sous un joli capot et hop ça y est le matraquage médiatique pour passer à une nouvelle version !
    Mais bon le Business à ses raisons que la raison ne sait pas !
    A
    Etienne ZINZINDOHOUE
    Billets-Articles

Discussions similaires

  1. Qu'est ce que cela veux dire un "code propre" selon-vous ?
    Par kagura dans le forum Général Conception Web
    Réponses: 45
    Dernier message: 09/02/2016, 14h22
  2. Quel est selon-vous le système idéal à la maison ?
    Par Community Management dans le forum Linux
    Réponses: 77
    Dernier message: 19/11/2015, 09h24
  3. Réponses: 51
    Dernier message: 15/03/2011, 15h51
  4. Quel est le meilleur générateur d'états selon vous ?
    Par Marc Lussac dans le forum Outils de restitution et d'analyse
    Réponses: 80
    Dernier message: 18/05/2010, 16h43
  5. Quel est selon vous le meilleur AV du marché ?
    Par lavazavio dans le forum Sécurité
    Réponses: 6
    Dernier message: 10/10/2005, 08h30

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