IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Schéma Discussion :

Packs de services


Sujet :

Schéma

  1. #1
    Membre expérimenté
    Homme Profil pro
    Inscrit en
    Janvier 2008
    Messages
    623
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : Janvier 2008
    Messages : 623
    Points : 1 370
    Points
    1 370
    Par défaut Packs de services
    Bonjour à tous,

    J'ai un modèle de données que voici :

    Nom : schema_bdd.png
Affichages : 292
Taille : 14,9 Ko

    Petites explications :
    Un utilisateur peut choisir un pack.
    Un pack contient un ou plusieurs services.
    Ce que je veux, c'est pouvoir savoir si un utilisateur a consommé un service dont il à souscrit (il manque un champ booléen dans la relation User_Service).

    Il me semble avoir vu quelque part qu'il faut éviter d'avoir plusieurs chemin pour retrouver une information.
    Dans mon cas, il y aurait effectivement 2 chemins pour retrouver les services d'un utilisateur.
    Est-ce vraiment un mauvaise chose.
    Si oui, comment modéliser mon problème de façon propre?

    Merci

  2. #2
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 965
    Points : 30 774
    Points
    30 774
    Billets dans le blog
    16
    Par défaut
    Bonsoir Farid,


    Citation Envoyé par FaridM
    Un utilisateur peut choisir un pack.
    Au plus un pack ? Je pars sur cette base.



    Citation Envoyé par FaridM
    Il me semble avoir vu quelque part qu'il faut éviter d'avoir plusieurs chemin pour retrouver une information.
    Il arrive qu’on ne puisse pas éviter cela, auquel cas on est amené à mettre en œuvre des contraintes de chemin, comme par exemple ici.

    Manifestement, vous êtes confronté à ce problème, mais votre modélisation n’est pas en cause. Cependant injecter des anomalies dans la base de données se fait sans aucune difficulté !

    Illustrons en passant à l'acte :

    
    CREATE TABLE SERVICE
    (
            service_id              CHAR(3)       NOT NULL
          , service_label           VARCHAR(32)   NOT NULL
        , CONSTRAINT SERVICE_PK PRIMARY KEY (service_id)          
    ) ;
    
    CREATE TABLE PACK
    (
            pack_id                 CHAR(3)       NOT NULL
          , pack_label              VARCHAR(32)   NOT NULL
        , CONSTRAINT PACK_PK PRIMARY KEY (pack_id)          
    ) ;
    
    CREATE TABLE PACK_SERVICE
    (
            pack_id                 CHAR(3)       NOT NULL
          , service_id              CHAR(3)       NOT NULL
        , CONSTRAINT PACK_SERVICE_PK PRIMARY KEY (pack_id, service_id)
        , CONSTRAINT PACK_SERVICE_PACK_FK FOREIGN KEY (pack_id) REFERENCES PACK (pack_id)     
        , CONSTRAINT PACK_SERVICE_SERVICE_FK FOREIGN KEY (service_id) REFERENCES SERVICE (service_id)  
    ) ;
    
    CREATE TABLE USER
    (
            user_id                 CHAR(3)       NOT NULL
          , user_nom                VARCHAR(32)   NOT NULL
          , pack_id                 CHAR(3)       NOT NULL      
        , CONSTRAINT USER_PK PRIMARY KEY (user_id) 
        , CONSTRAINT USER_PACK_FK FOREIGN KEY (pack_id) REFERENCES PACK (pack_id)     
    ) ;
    
    CREATE TABLE USER_SERVICE
    (
            user_id                 CHAR(3)       NOT NULL
          , service_id              CHAR(3)       NOT NULL
        , CONSTRAINT USER_SERVICE_PK PRIMARY KEY (user_id, service_id) 
        , CONSTRAINT USER_SERVICE_USER_FK FOREIGN KEY (user_id) REFERENCES USER (user_id)     
        , CONSTRAINT USER_SERVICE_SERVICE_FK FOREIGN KEY (service_id) REFERENCES SERVICE (service_id)  
    ) ;
    
    INSERT INTO SERVICE (service_id, service_label) VALUES
        ('s01', 'service 01'), ('s02', 'service 02'), ('s03', 'service 03'), ('s04', 'service 04'), ('s05', 'service 05') 
    ;    
    
    INSERT INTO PACK (pack_id, pack_label) VALUES
        ('p01', 'pack 01'), ('p02', 'pack 02'), ('p03', 'pack 03'), ('p04', 'pack 04'), ('p05', 'pack 05') 
    ;
    
    INSERT INTO PACK_SERVICE (pack_id, service_id) VALUES
        ('p01', 's01'), ('p01', 's02'), ('p01', 's03')
      , ('p02', 's02'), ('p02', 's03'), ('p02', 's04')
      , ('p03', 's03'), ('p03', 's04'), ('p03', 's05')  
    ;
    
    INSERT INTO USER (user_id, user_nom, pack_id) VALUES
        ('u01', 'user 01', 'p01'), ('u02', 'user 02', 'p01'), ('u03', 'user 03', 'p03'), ('u04', 'user 04', 'p04')
    ;
    
    INSERT INTO USER_SERVICE (user_id, service_id) VALUES
        ('u01', 's05'), ('u02', 's03'), ('u02', 's04'), ('u04', 's01')
    ;
    
    

    Recherche des situations normales :

    
    SELECT u.user_id, u.pack_id, us.service_id 
    FROM   USER AS u JOIN USER_SERVICE AS us ON u.user_id = us.user_id
                     JOIN PACK_SERVICE AS ps ON us.service_id = ps.service_id
                     JOIN PACK AS p ON ps.pack_id = p.pack_id AND u.pack_id = p.pack_id
    ORDER BY u.user_id, u.pack_id
    ;    
    
    
    =>

    
    user_id    pack_id    service_id
    -------    -------    ----------
    u02        p01        s03
    
    

    Recherche des anomalies

    
    SELECT DISTINCT u.user_id, u.pack_id, ps.pack_id AS pack_id_a_refuser
    FROM   USER AS u JOIN USER_SERVICE AS us ON u.user_id = us.user_id
                     JOIN PACK_SERVICE AS ps ON us.service_id = ps.service_id 
    WHERE NOT EXISTS (SELECT ''
                      FROM   PACK AS p
                      WHERE  u.pack_id = p.pack_id AND ps.pack_id = p.pack_id)
    ;                  
    
    
    =>

    
    user_id    pack_id    pack_id_a_refuser
    -------    -------    -----------------
    u01        p01        p03
    u02        p01        p02
    u02        p01        p03
    u04        p04        p01
    
    
    En conséquence, il faudra mettre en œuvre un trigger pour rejeter les ajouts provoquant des anomalies (même chose pour les modifications). La table à laquelle s’applique le trigger est la table USER_SERVICE, la règle à faire respecter étant la suivante :

    Les services consommés par un utilisateur doivent tous être associés au pack choisi par cet utilisateur.

    Autrement dit, en ce qui concerne les ajouts, pour l’utilisateur {user_id} ayant choisi un pack {pack_id} et un (ou plusieurs) service(s) {service_id}, chaque valeur de la paire {pack_id, service_id} doit être une valeur appartenant à la table PACK_SERVICE.

    Le code du trigger dépend de votre SGBD.

    D'autres triggers seront à prévoir concernant cette fois-ci la table PACK_SERVICE, au cas où on peut y supprimer ou modifier des lignes...

    J'espère ne pas vous avoir mis le moral dans les chaussettes...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  3. #3
    Membre expérimenté
    Homme Profil pro
    Inscrit en
    Janvier 2008
    Messages
    623
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : Janvier 2008
    Messages : 623
    Points : 1 370
    Points
    1 370
    Par défaut
    Bonsoir fsmrel, merci pour votre réponse.

    C'est bien un pack par utilisateur.
    Donc ma conception, il ne me reste plus qu'a blinder l' le SGBD pour éviter les erreurs.

    Citation Envoyé par fsmrel Voir le message
    J'espère ne pas vous avoir mis le moral dans les chaussettes...
    Pas du tout.
    Ma conception est bonne, c'est déjà.

    Encore merci.

  4. #4
    Membre expérimenté
    Homme Profil pro
    Inscrit en
    Janvier 2008
    Messages
    623
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : Janvier 2008
    Messages : 623
    Points : 1 370
    Points
    1 370
    Par défaut
    Il y a du changement.

    Un utilisateur peut vouloir souscrire à un autre pack.

    Après réflexion, j'obtiens ce schéma :

    Nom : schema2.png
Affichages : 261
Taille : 29,4 Ko

    Je me retrouve donc avec une relation ternaire et avec un sorte de double relation entre Pack et Service.
    Du coup je suis pas très convaincu de ce schéma.
    Je pense que je peux me passer de la relation entre Pack et User puisque je peux récupérer les packs en question en passant par Service.

    Qu'en pensez-vous?

  5. #5
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 965
    Points : 30 774
    Points
    30 774
    Billets dans le blog
    16
    Par défaut Contrainte d'inclusion
    Bonsoir Farid,


    Vous voici aux prises avec cette fois-ci une contrainte d’inclusion (cas particulier de la contrainte de chemin)...

    Vous ne pouvez pas faire l’économie de l’association PACK_SERVICE, car elle représente un référentiel, un catalogue : cette association devra donc impérativement donner lieu à la table PACK_SERVICE que l’on connaît déjà.

    L’association ternaire est légitime, mais un utilisateur ne doit pouvoir utiliser que des services de packs présents dans PACK_SERVICE, d’où la contrainte d’inclusion (représentée ici avec l’AGL DB-MAIN) entre les associations PACK_SERVICE et USER_PACK_SERVICE :






    Au stade relationnel, la table USER_PACK_SERVICE sera dotée d’une clé étrangère référençant la table PACK_SERVICE, tandis que les clés étrangères référençant les tables PACK et SERVICE deviennent sans emploi et disparaissent donc.

    Le code SQL devient le suivant :

    
    CREATE TABLE SERVICE
    (
            service_id              CHAR(3)       NOT NULL
          , service_label           VARCHAR(32)   NOT NULL
        , CONSTRAINT SERVICE_PK PRIMARY KEY (service_id)          
    ) ;
    
    CREATE TABLE PACK
    (
            pack_id                 CHAR(3)       NOT NULL
          , pack_label              VARCHAR(32)   NOT NULL
        , CONSTRAINT PACK_PK PRIMARY KEY (pack_id)          
    ) ;
    
    CREATE TABLE PACK_SERVICE
    (
            pack_id                 CHAR(3)       NOT NULL
          , service_id              CHAR(3)       NOT NULL
        , CONSTRAINT PACK_SERVICE_PK PRIMARY KEY (pack_id, service_id)
        , CONSTRAINT PACK_SERVICE_PACK_FK FOREIGN KEY (pack_id) REFERENCES PACK (pack_id)     
        , CONSTRAINT PACK_SERVICE_SERVICE_FK FOREIGN KEY (service_id) REFERENCES SERVICE (service_id)  
    ) ;
    
    CREATE TABLE USER
    (
            user_id                 CHAR(3)       NOT NULL
          , user_nom                VARCHAR(32)   NOT NULL     
        , CONSTRAINT USER_PK PRIMARY KEY (user_id)     
    ) ;
    
    CREATE TABLE USER_PACK_SERVICE
    (
            user_id                 CHAR(3)       NOT NULL
          , pack_id                 CHAR(3)       NOT NULL        
          , service_id              CHAR(3)       NOT NULL
          , consumed                INT           NOT NULL      
        , CONSTRAINT USER_SERVICE_PK PRIMARY KEY (user_id, pack_id, service_id) 
        , CONSTRAINT USER_SERVICE_USER_FK FOREIGN KEY (user_id) REFERENCES USER (user_id)     
        , CONSTRAINT USER_SERVICE_PACK_FK FOREIGN KEY (pack_id, service_id) REFERENCES PACK_SERVICE (pack_id, service_id)  
    ) ;
    
    INSERT INTO SERVICE (service_id, service_label) VALUES
        ('s01', 'service 01'), ('s02', 'service 02'), ('s03', 'service 03'), ('s04', 'service 04'), ('s05', 'service 05') 
    ;    
    
    INSERT INTO PACK (pack_id, pack_label) VALUES
        ('p01', 'pack 01'), ('p02', 'pack 02'), ('p03', 'pack 03'), ('p04', 'pack 04'), ('p05', 'pack 05') 
    ;
    
    INSERT INTO PACK_SERVICE (pack_id, service_id) VALUES
        ('p01', 's01'), ('p01', 's02'), ('p01', 's03')
      , ('p02', 's02'), ('p02', 's03'), ('p02', 's04')
      , ('p03', 's03'), ('p03', 's04'), ('p03', 's05')  
    ;
    
    INSERT INTO USER (user_id, user_nom) VALUES
         ('u01', 'user 01'), ('u02', 'user 02'), ('u03', 'user 03'), ('u04', 'user 04')
    ;
    
    INSERT INTO USER_PACK_SERVICE (user_id, pack_id, service_id, consumed) VALUES
        ('u01', 'p03', 's05', 25), ('u02', 'p03', 's03', 10), ('u02', 'p03', 's04', 54), ('u04', 'p01', 's03', 20)
    ;
    
    SELECT * FROM USER_PACK_SERVICE ;
    
    

    The good news : Adieu les triggers !
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  6. #6
    Membre expérimenté
    Homme Profil pro
    Inscrit en
    Janvier 2008
    Messages
    623
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : Janvier 2008
    Messages : 623
    Points : 1 370
    Points
    1 370
    Par défaut
    Encore merci pour votre retour.

    Par contre, ici, un utilisateur ne peux pas choisir 2 fois le même pack.
    Il faudrait donc que je change la clé primaire de la table USER_PACK_SERVICE en rajoutant un identifiant unique (entier auto-incrémenté ?).

    Je me rends compte qu'utiliser un ORM, c'est pas forcément un avantage...

  7. #7
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 965
    Points : 30 774
    Points
    30 774
    Billets dans le blog
    16
    Par défaut
    Bonsoir Farid,


    Qu’entendez-vous par « ici » ? Dans ce que je vous ai proposé, un utilisateur peut choisir deux fois le même pack, puisque c’est le but de la manœuvre. Voyez dans le dernier code SQL le cas de l’utilisateur u02 : il a bien choisi deux fois le pack p03 (pour les services s03 et s04).
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  8. #8
    Membre expérimenté
    Homme Profil pro
    Inscrit en
    Janvier 2008
    Messages
    623
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : Janvier 2008
    Messages : 623
    Points : 1 370
    Points
    1 370
    Par défaut
    Je voulais dire le même pack avec les mêmes services.

    Par exemple, le 15/01/2015, l'utilisateur u01 achètes le pack p01 qui lui même comprend les services s01, s02, s03.
    Nous avons donc :

    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    INSERT INTO USER_PACK_SERVICE (user_id, pack_id, service_id, consumed) VALUES
        ('u01', 'p01', 's01', false), ('u01', 'p01, 's02', false), ('u01', 'p01', 's03', false);

    Le 15/01/2016, u01 à consommé les services qu'il avait acheté, il souhaite donc recommander le même pack avec les mêmes services est donc la requête précédente est réexecutée.
    On se retrouve donc avec une violation de contrainte sur la clé primaire : CONSTRAINT USER_SERVICE_PK PRIMARY KEY (user_id, pack_id, service_id)

  9. #9
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 965
    Points : 30 774
    Points
    30 774
    Billets dans le blog
    16
    Par défaut
    Bonsoir Farid,


    Si un utilisateur peut acheter plusieurs fois la même paire {Pack, Service}, pas de problème, on intègre la date d’achat dans la clé :






    Au stade SQL :

    
    
    CREATE TABLE USER_PACK_SERVICE
    (
            user_id                 CHAR(3)       NOT NULL
          , pack_id                 CHAR(3)       NOT NULL        
          , service_id              CHAR(3)       NOT NULL
          , consumed                INT           NOT NULL
          , date_achat              DATE          NOT NULL      
        , CONSTRAINT USER_SERVICE_PK PRIMARY KEY (user_id, pack_id, service_id, date_achat) 
        , CONSTRAINT USER_SERVICE_USER_FK FOREIGN KEY (user_id) REFERENCES USER (user_id)     
        , CONSTRAINT USER_SERVICE_PACK_FK FOREIGN KEY (pack_id, service_id) REFERENCES PACK_SERVICE (pack_id, service_id)  
    ) ;
    
    
    INSERT INTO USER_PACK_SERVICE (user_id, pack_id, service_id, consumed, date_achat) VALUES
        ('u01', 'p03', 's05', 25, '2015-01-01'), ('u02', 'p03', 's03', 10, '2015-01-01'), ('u02', 'p03', 's04', 54, '2015-01-01'), ('u04', 'p01', 's03', 20, '2015-01-01')
    ;
    
    INSERT INTO USER_PACK_SERVICE (user_id, pack_id, service_id, consumed, date_achat) VALUES
        ('u01', 'p03', 's05', 25, '2015-01-02'), ('u02', 'p03', 's03', 10, '2015-01-02'), ('u02', 'p03', 's04', 54, '2015-01-02'), ('u04', 'p01', 's03', 20, '2015-01-02')
    ;
    
    

    Si un utilisateur peut acheter plus d’une fois le même pack dans la journée, on fera participer l’heure d’achat à la clé. Si l’utilisateur peut acheter le même pack au même moment, on fera participer la quantité à la clé, ou bien on fera de l’incrémentation relative...

    Qu’en est-il ? Un utilisateur peut-il acheter plus d’une fois le même pack dans la journée ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  10. #10
    Membre expérimenté
    Homme Profil pro
    Inscrit en
    Janvier 2008
    Messages
    623
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : Janvier 2008
    Messages : 623
    Points : 1 370
    Points
    1 370
    Par défaut
    Un utilisateur peut acheter qu'un pack par jour, donc la date devrait suffire.

  11. #11
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 965
    Points : 30 774
    Points
    30 774
    Billets dans le blog
    16
    Par défaut
    Donc tout est pour le mieux

    En passant, n'hésitez pas à voter pour les messages qui vous ont été utiles.

    Bonne route !
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

Discussions similaires

  1. [MySQL] Liaison entre plusieurs tables
    Par matt7575 dans le forum PHP & Base de données
    Réponses: 13
    Dernier message: 16/01/2010, 15h59
  2. Réponses: 13
    Dernier message: 22/08/2009, 16h53
  3. Réponses: 1
    Dernier message: 22/08/2007, 01h05
  4. Liaison entre plusieurs projet d'une solution
    Par jeremycs dans le forum Windows Forms
    Réponses: 1
    Dernier message: 16/02/2007, 14h38
  5. liaison entre plusieurs base de donnee
    Par GMI dans le forum Bases de données
    Réponses: 1
    Dernier message: 15/12/2004, 19h42

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