Salem tout le monde
voila mon problème , j'ai fait un schéma entité-association de mon base de donnée mais je pense qu'il y a un erreur dans mon diagramme , aidez moi svp
merci d'avance.
Salem tout le monde
voila mon problème , j'ai fait un schéma entité-association de mon base de donnée mais je pense qu'il y a un erreur dans mon diagramme , aidez moi svp
merci d'avance.
Bonjour,
A priori, il y a un problème car je retrouve plusieurs boucles dans ton modèle E-A. Bien vouloir revoir les règles de gestion.
Bonjour,
Pour traiter ta demande, il me semble que tu ne sois pas dans le bon forum. A mon avis, il vaut mieux poster ici.
http://www.developpez.net/forums/f62...sation/schema/
Sur ce forum, tu as les vrais spécialistes du MCD comme fsmrel et autres (que je salue au passage), ils vont te mettre sur la bonne voie et t'expliquer les erreurs à ne pas commettre.
J'ai survolé ton MCD. Effectivement, il est nécessaire de le revoir.
Bon courage
Bonjour à tous,
Je vais essayer de trouver un moment pour regarder tout ça, mais il y aura une remise à plat complète...
A plus tard,
François
Comme aurait pu dire Françoise Sagan, Bonjour Sourire,
Pour commencer, faut pas pleurer ^^
L’objet de votre modélisation a trait aux achats et ventes d’un seul et non pas de plusieurs pépiniéristes, en conséquence de quoi il est inutile de modéliser une entité-type PÉPINIÉRISTE. Pour la petite histoire, les théoriciens aiment bien donner un nom à l’objet unique de notre préoccupation et qui est au coeur de la modélisation, ils appellent cet objet « univers du discours » (ou plus simplement univers) et dans votre cas, il s’agit de l’activité d’une pépinière, on pourra donc appeler cet univers : PÉPINIÈRE. Ça peut vous faire de la peine, mais il en ressort que l’entité-type PÉPINIÉRISTE doit être retirée de votre MCD.
Par ailleurs, comme tous les énoncés qui ne sont pas accompagnés d’exemples, l’interprétation que nous en faisons n’est que rarement celle de celui qui l’a rédigé... Un énoncé de ce genre comporte en général des ambiguïtés, des flous, des manques, mais on fera avec.
Quoi qu’il en soit, je vous laisse réfléchir à cette ébauche provisoire, non dérivable en l’état (traitement des retoursà aménager) et que seabs se fera un plaisir de commenter (de façon positive j’espère)^^...
J’ai des remarques que j’ai commencé à rédiger et que je vous soumettrai. En attendant, bon courage !
merci fsmrel c trés gentil , 10000000 merciiiiiiii
Pour la requete 3, c'est juste ou nn !!!
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7 select f.FournId , v.VégétaleId, v.VégétaleNom from Végétale v , Fournisseur f ,Retour r,Achat ac where v.VégétaleId =r.VégétaleId And r.AchatId=ac.AchatId And ac.FournId=f.FournId; Group by f.FournId,v.VégétaleId, v.VégétaleNom;
Bonjour Sourire,
Vous allez plus vite que la musqiue ! Où est votre MLD ? Quel est votre SGBD ?
Par ailleurs, je sui occupé jusqu'à ce soir, je ne pourrai pas répondre avant cette nuit...
En attendant, bon courage !
voila le Schéma relationnel :
Lot ( LotId, # FournId, LotDate, LotMantant, LotQte).
Fournisseur (FournId, FourNom, fourVille, FourcCodePostal, FourPays).
Achat (AchatId, #FournId, #VégétaleId , #JardinId, AchatDate, AchatMantant, AchatQte).
Client (ClientId, ClientNom,ClientPrénom , date _nais).
Jardin (JardinId, #ClientId, JardinVille, JardinPays, JardinCodePostal ).
Végétale (VégétaleId, #EspèceId, VégétaleNom).
Espèce ( EspèceId , EspèceNom ).
Retour (RetourId ,#AchatId, #VégétaleId, RetourDate, RetourQte, RetourMotif).
Composer (#LotId, #VégétaleId ).
Accorder (#AchatId, #RetourId).
merci d’avance
Bonjour Sourire,
Vous voulez aller vite et on le comprend, néanmoins il faut d’abord s’assurer de la solidité des fondements de l’édifice, que l’énoncé qu'on a vous a fourni soit limpide ou flou...
Dans le MCD que je vous ai proposé la dernière fois, j’ai fait figurer une association COMPOSER (que je renomme en COMPOSITION dans le code SQL) : son rôle est de permettre de garantir les contraintes C1 et C2 suivantes :
(C1) L’achat effectué par un client doit concerner un végétal d’une espèce entrant dans la composition du lot fourni au pépiniériste par le fournisseur mentionné dans l’achat.
(C2) La date d’achat d’un végétal par un client ne doit pas être antérieure à la date à laquelle un fournisseur a fourni ce végétal au pépiniériste.
Partons de l’extrait suivant du MCD (dont sont absents JARDIN, etc., dont on n'a pas besoin pour le moment) :
MLD correspondant :
Code SQL :
Table FOURNISSEUR
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 CREATE TABLE FOURNISSEUR ( FourId CHAR(3) NOT NULL , FourNom VARCHAR(64) NOT NULL , CONSTRAINT FOURNISSEUR_PK PRIMARY KEY (FourId) ) ;
Table ESPECE
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 CREATE TABLE ESPECE ( EspeceId CHAR(3) NOT NULL , EspeceNom VARCHAR(64) NOT NULL , CONSTRAINT ESPECE_PK PRIMARY KEY (EspeceId) ) ;
Table VEGETAL
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 CREATE TABLE VEGETAL ( VegetalId CHAR(3) NOT NULL , EspeceId CHAR(3) NOT NULL , VegetalNom VARCHAR(64) NOT NULL , CONSTRAINT VEGETAL_PK PRIMARY KEY (VegetalId) , CONSTRAINT VEGETAL_ESPECE_FK FOREIGN KEY (EspeceId) REFERENCES ESPECE ) ;
Table LOT
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10 CREATE TABLE LOT ( LotId CHAR(3) NOT NULL , FourId CHAR(3) NOT NULL , LotDate DATE NOT NULL , LotMontant DECIMAL(10,2) NOT NULL , LotQuantite INT NOT NULL , CONSTRAINT LOT_PK PRIMARY KEY (LotId) , CONSTRAINT LOT_FOURNISSEUR_FK FOREIGN KEY (FourId) REFERENCES FOURNISSEUR ) ;
Table COMPOSITION (association COMPOSER du MCD)
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 CREATE TABLE COMPOSITION ( LotId CHAR(3) NOT NULL , VegetalId CHAR(3) NOT NULL , CONSTRAINT COMPOSITION_PK PRIMARY KEY (LotId, VegetalId) , CONSTRAINT COMPOSITION_LOT_FK FOREIGN KEY (LotId) REFERENCES LOT , CONSTRAINT COMPOSITION_VEGETAL_FK FOREIGN KEY (VegetalId) REFERENCES VEGETAL ) ;
Table ACHAT
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12 CREATE TABLE ACHAT ( , AchatId CHAR(3) NOT NULL , AchatDate DATE NOT NULL , AchatMontant DECIMAL(10,2) NOT NULL , AchatQte INT NOT NULL , VegetalId CHAR(3) NOT NULL , FourId CHAR(3) NOT NULL , CONSTRAINT ACHAT_PK PRIMARY KEY (AchatId) , CONSTRAINT ACHAT_VEGETAL_FK FOREIGN KEY (VegetalId) REFERENCES VEGETAL , CONSTRAINT ACHAT_FOURNISSEUR_FK FOREIGN KEY (FourId) REFERENCES FOURNISSEUR ) ;
Pour garantir les contraintes C1 et C2 lors des mises à jour de la table ACHAT, si votre SGBD ne propose pas l’instruction CREATE ASSERTION, vous pouvez mettre en œuvre un trigger.
Exemple avec MS SQL Server :
Code SQL : 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 CREATE TRIGGER ACHAT_INSERT ON ACHAT INSTEAD OF INSERT, UPDATE AS DECLARE @N AS INT ; SET @N = (SELECT COUNT(*) FROM (SELECT x.AchatId FROM INSERTED AS x INNER JOIN VEGETAL AS y ON x.VegetalId = y.VegetalId INNER JOIN COMPOSITION AS z ON y.VegetalId = z.VegetalId INNER JOIN LOT AS t ON z.LotId = t.LotId INNER JOIN FOURNISSEUR AS u ON x.FourId = u.FourId AND (x.FourId <> t.FourId OR x.AchatDate < t.LotDate)) AS truc) IF @N > 0 BEGIN RAISERROR ('Achat incompatible...',15,1) END ELSE BEGIN INSERT INTO ACHAT SELECT * FROM INSERTED END
A suivre...
Variation...
Revenons sur la contrainte C1 :
(C1) L’achat effectué par un client doit concerner un végétal d’une espèce entrant dans la composition du lot fourni au pépiniériste par le fournisseur mentionné dans l’achat.
Dans le MCD précédent, l’association COMPOSER (renommée en COMPOSITION dans le code SQL) prévue pour C1, connecte LOT et VEGETAL, mais elle peut très bien connecter LOT et ESPECE, à vous de choisir. ^^
La variante MCD est la suivante :
MLD correspondant :
Le code SQL est identique au précédent, sauf évidemment pour la table COMPOSITION :
Table FOURNISSEUR
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 CREATE TABLE FOURNISSEUR ( FourId CHAR(3) NOT NULL , FourNom VARCHAR(64) NOT NULL , CONSTRAINT FOURNISSEUR_PK PRIMARY KEY (FourId) ) ;
Table ESPECE
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 TABLE ESPECE ( EspeceId CHAR(3) NOT NULL , EspeceNom VARCHAR(64) NOT NULL , CONSTRAINT ESPECE_PK PRIMARY KEY (EspeceId) ) ;
Table VEGETAL
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 CREATE TABLE VEGETAL ( VegetalId CHAR(3) NOT NULL , EspeceId CHAR(3) NOT NULL , VegetalNom VARCHAR(64) NOT NULL , CONSTRAINT VEGETAL_PK PRIMARY KEY (VegetalId) , CONSTRAINT VEGETAL_ESPECE_FK FOREIGN KEY (EspeceId) REFERENCES ESPECE ) ;
Table LOT
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10 CREATE TABLE LOT ( LotId CHAR(3) NOT NULL , FourId CHAR(3) NOT NULL , LotDate DATE NOT NULL , LotMontant DECIMAL(10,2) NOT NULL , LotQuantite INT NOT NULL , CONSTRAINT LOT_PK PRIMARY KEY (LotId) , CONSTRAINT LOT_FOURNISSEUR_FK FOREIGN KEY (FourId) REFERENCES FOURNISSEUR ) ;
Table COMPOSITION
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 CREATE TABLE COMPOSITION (association COMPOSER du MCD) ( LotId CHAR(3) NOT NULL , EspeceId CHAR(3) NOT NULL , CONSTRAINT COMPOSITION_PK PRIMARY KEY (LotId, EspeceId) , CONSTRAINT COMPOSITION_LOT_FK FOREIGN KEY (LotId) REFERENCES LOT , CONSTRAINT COMPOSITION_ESPECE_FK FOREIGN KEY (EspeceId) REFERENCES ESPECE ) ;
Table ACHAT
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12 CREATE TABLE ACHAT ( , AchatId CHAR(3) NOT NULL , AchatDate DATE NOT NULL , AchatMontant DECIMAL(10,2) NOT NULL , AchatQte INT NOT NULL , VegetalId CHAR(3) NOT NULL , FourId CHAR(3) NOT NULL , CONSTRAINT ACHAT_PK PRIMARY KEY (AchatId) , CONSTRAINT ACHAT_VEGETAL_FK FOREIGN KEY (VegetalId) REFERENCES VEGETAL , CONSTRAINT ACHAT_FOURNISSEUR_FK FOREIGN KEY (FourId) REFERENCES FOURNISSEUR ) ;
Le trigger prévu pour garantir la contrainte C1 évolue en conséquence :
Code SQL : 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 CREATE TRIGGER ACHAT_INSERT ON ACHAT INSTEAD OF INSERT, UPDATE AS DECLARE @N AS INT ; SET @N = (SELECT COUNT(*) FROM (SELECT x.AchatId FROM INSERTED AS x INNER JOIN VEGETAL AS y ON x.VegetalId = y.VegetalId INNER JOIN ESPECE AS e ON y.EspeceId = e.EspeceId INNER JOIN COMPOSITION AS z ON z.EspeceId = e.EspeceId INNER JOIN LOT AS t ON z.LotId = t.LotId INNER JOIN FOURNISSEUR AS u ON x.FourId = u.FourId AND (x.FourId <> t.FourId OR x.AchatDate < t.LotDate)) AS truc) IF @N > 0 BEGIN RAISERROR ('Achat incompatible...',15,1) END ELSE BEGIN INSERT INTO ACHAT SELECT * FROM INSERTED END
A suivre (ne me bombardez pas, je vais à mon rythme...) ^^
C'est pas un peu poussé la notion de trigger pour une débutante en modélisation ? Elle va se faire cramer si elle doit rendre ça
Bonne année Sourire,
Toujours à mon rythme...
Passons à une partie ne présentant pas de difficulté : enrichissons le MCD avec les entités-types CLIENT et JARDIN. Étant donné que les fournisseurs et les jardins partagent des propriétés communes : ville, code postal et pays, on peut factoriser ces propriétés dans une entité-type, appelons-la par exemple LOCALITE.
Cette partie du MCD devient la suivante :
MLD correspondant
La partie SQL est complétée ainsi :
TABLE LOCALITE
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 CREATE TABLE LOCALITE ( LocaliteId CHAR(3) NOT NULL , LocaliteNom VARCHAR(64) NOT NULL , LocaliteCodePostal CHAR(5) NOT NULL , LocalitePays VARCHAR(64) NOT NULL , CONSTRAINT LOCALITE_PK PRIMARY KEY (LocaliteId) ) ;
TABLE FOURNISSEUR
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 CREATE TABLE FOURNISSEUR ( FourId CHAR(3) NOT NULL , FourNom VARCHAR(64) NOT NULL , LocaliteId CHAR(3) NOT NULL , CONSTRAINT FOURNISSEUR_PK PRIMARY KEY (FourId) , CONSTRAINT FOURNISSEUR_LOCALITE_FK FOREIGN KEY (LocaliteId) REFERENCES LOCALITE ) ;
TABLE CLIENT
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7 CREATE TABLE CLIENT ( ClientId CHAR(4) NOT NULL , CLientNom VARCHAR(64) NOT NULL , CLientPrenom VARCHAR(64) NOT NULL , CONSTRAINT CLIENT_PK PRIMARY KEY (ClientId) ) ;
TABLE JARDIN
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9 CREATE TABLE JARDIN ( JardinId CHAR(3) NOT NULL , ClientId CHAR(4) NOT NULL , LocaliteId CHAR(3) NOT NULL , CONSTRAINT JARDIN_PK PRIMARY KEY (JardinId) , CONSTRAINT JARDIN_CLIENT_FK FOREIGN KEY (ClientId) REFERENCES CLIENT , CONSTRAINT JARDIN_LOCALITE_FK FOREIGN KEY (LocaliteId) REFERENCES LOCALITE ) ;
TABLE ACHAT
Code SQL : 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 ACHAT ( AchatId CHAR(3) NOT NULL , FourId CHAR(3) NOT NULL , VegetalId CHAR(3) NOT NULL , JardinId CHAR(3) NOT NULL , AchatDate DATE NOT NULL , AchatMontant DECIMAL(10,2) NOT NULL , AchatQte INT NOT NULL , CONSTRAINT ACHAT_PK PRIMARY KEY (AchatId) , CONSTRAINT ACHAT_FOURNISSEUR_FK FOREIGN KEY (FourId) REFERENCES FOURNISSEUR , CONSTRAINT ACHAT_VEGETAL_FK FOREIGN KEY (VegetalId) REFERENCES VEGETAL , CONSTRAINT ACHAT_JARDIN_FK FOREIGN KEY (JardinId) REFERENCES JARDIN ) ;
Attaquons la partie plus délicate, ayant trait aux retours de marchandises... Selon l’énoncé qui vous est proposé, un achat peut donc faire l’objet d’un retour.
Supposons que l’achat du client Volfoni porte sur douze pommiers de la variété « Malus domestica 'Transparente de Croncels' » et qu’à la réception, trois d’entre eux s’avèrent détériorés et, pourquoi pas ! deux autres non conformes (en fait de pommiers, il s’agirait de sapins...) Restons néanmoins dans un contexte homogène (je ne voudrais pas vous traumatiser), on va donc admettre que M. Volfoni n’aura reçu que des pommiers, dont trois inutilisables et qu’il ne manquera pas de retourner.
Du point de vue merisien, une modélisation des retours peut être la suivante :
Version Merise 1re génération :
Conceptuellement c’est valide. Mais il y a un problème lors du passage du MCD (schéma entité-association) au MLD (schéma relationnel), car les règles de transformation des associations sont traditionnellement trop simples et donnent lieu ici à un cycle (chose propre à semer la panique dans les bases de données) :
Non seulement l’entité-type RETOUR a son propre identifiant RetourId, alors que AchatId y est identifiant alternatif (et suffit en fait pour identifier RETOUR), mais en plus RetourId vient polluer ACHAT, alors que tous les achats ne font pas l’objet d’un retour (heureusement, sinon le pépiniériste pourrait mettre la clé sous la porte !)
Essayons d’améliorer en utilisant Merise 2e génération (utilisation de l’identification relative) :
a) Notation PowerAMC (cardinalité 1,1 mise entre parenthèses) :
b) Notation WinDesign :
Dans ces deux derniers cas, l’entité-type RETOUR hérite de l’identifiant d’ACHAT (AchatId), en lieu et place de RetourId, ce qui est préférable. Malheureusement, comme on le voit ci-dessous, le cycle est toujours présent (testé en tout cas avec PowerAMC), car la clé étrangère {AchatRetourId} appartenant à la table ACHAT fait référence à la clé primaire {AchatId} de la table RETOUR, donc transitivement ACHAT se fait référence (et on doit donc s’assurer que dans cette table, AchatId = AchatRetourId...) :
Pour éviter la génération dans la table ACHAT de la clé étrangère {AchatRetourId} parasite et propre à ficher la zoubia, utilisons une représentation entité-association selon PowerAMC :
La lettre D entre parenthèses signifie que RETOUR dépend d’ACHAT (et pas l’inverse) et qu’en conséquence il n’y aura pas de génération de cycle. Par ailleurs Le mickey « ⊳ » signifie que l’identifiant de RETOUR est hérité de celui d’ACHAT.
Dérivation en MLD :
Passons à la décision actée par le pépiniériste de remplacer les 3 pommiers litigieux de M. Volfoni.
Étant donné qu’entre le retour et l’accord de remplacement (si donc il se produit), il peut s’écouler un certain temps, on peut choisir de modéliser une entité-type ad-hoc, appelons-la ACCORD_REMPLACEMENT :
On identifie l’entité-type ACCORD_REMPLACEMENT relativement à l’entité-type RETOUR, et en rendant la 1re dépendante de la 2e (entité-type plus forte), ainsi on évite à nouveau un cycle.
Un accord de remplacement fait à son tour l’objet d’un nouvel achat, d’où la l’association entre les entités-types ACCORD_REMPLACEMENT et ACHAT, tout en évitant un cycle :
Dérivation en MLD (schéma relationnel) :
Pour y voir plus clair (mais si !), on a renommé l’attribut AchatId de la table RETOUR en AchatInitialId. Pour en revenir à l’achat initial de M. Volfoni, si l’identifiant AchatId de cet achat a pour valeur 123456 (table ACHAT), l’identifiant AchatInitialId de la table RETOUR y fera référence, donc avec la valeur 123456. Après l’accord de remplacement des 3 pommiers inutilisables, M. Volfoni aura droit à un achat gratuit, repéré dans la table ACHAT par un tuple de clé disons 314116, référencée par l’attribut AchatRemplacementId de la table ACCORD_REMPLACEMENT.
Reste le problème des végétaux choisis par M. Volfoni, car selon l’énoncé, les pommiers inutilisables peuvent être remplacés par des végétaux de la même espèce.
Je n’y connais rien en horticulture mais pour être essayer d’être pertinent, je fais référence à ce que proposent les excellentes Pépinières Rouxel, qui nous apprennent que le pommier « Malus domestica 'Transparente de Croncels' » est un cultivar (même chose pour le pommier « Malus domestica 'Golden Delicious' »), c'est-à-dire une variété végétale, de l’espèce « Malus Domestica » :
Clairement, ce que votre énoncé appelle « végétal » correspond donc au cultivar, en conséquence de quoi, puisqu’il y est écrit qu’« un végétal est d’une espèce donnée », vu la hiérarchie taxonomique ci-dessus, les « Malus domestica 'Transparente de Croncels' » achetés initialement par M. Volfoni peuvent être remplacés par des « Malus domestica 'Golden Delicious' ».
Comme par hasard, M. Volfoni demandera qu’on remplace les 3 pommiers « Malus domestica 'Transparente de Croncels' » défectueux par deux pommiers « Malus domestica 'Transparente de Croncels' » et un pommier « Malus domestica 'Golden Delicious' ».
Toutefois, ça paraît difficile, car votre énoncé comporte une sorte de contradiction : il précise en effet d’une part que des végétaux défectueux peuvent être remplacés par d’autres, de même espèce, ce dont on vient de traiter, mais il est aussi précisé que le remplacement ne pourra faire l’objet que d’un unique autre achat (gratuit), or un achat ne peut faire mention que d’un seul type de végétal, donc de pommier dans le cas de M. Volfoni...
A supposer qu’on veuille malgré tout remplacer les 3 pommiers « Malus domestica 'Transparente de Croncels' » par deux pommiers « Malus domestica 'Transparente de Croncels' » et un pommier « Malus domestica 'Golden Delicious' », alors il y faudra deux achats gratuits, un par type de végétal.
A vous de jouer.
N.B. Il y a certaines contraintes d’intégrité à garantir :
Dans le cas de la table ACCORD_REMPLACEMENT, on doit s’assurer que les attributs AchatInitialId et AchatRemplacementId ont des valeurs différentes, on doit aussi s’assurer que la date de retour (attribut RetourDate de la table RETOUR) ne soit pas antérieure à la date d’achat initial (attribut AchatDate de la table ACHAT, que la date d’accord (attribut DateAccord de la table ACCORD_REMPLACEMENT) ne soit pas antérieure à la date de retour, que la date de l’achat gratuit ne soit pas antérieure à la date de l’accord, j’en passe et des meilleures quant aux quentités, etc. ^^)
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager