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

 MySQL Discussion :

Aide sur la création d'une bdd sous MySQL


Sujet :

MySQL

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2006
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 22
    Points : 10
    Points
    10
    Par défaut Aide sur la création d'une bdd sous MySQL
    Bonjour,

    Edit: je laisse mon message initial, je devais faire une base sous Access, j'ai changer d'idée et décider de la faire sous My SQL.

    Je suis actuellement étudiant en alternance, dans le cadre de mon travail en entreprise, on me demande de crée une bdd sous Access.
    Le devellopement de base de données n'étant pas mon domaine de prédilection, je me permet de poster un message ici pour recevoir l'aide de personne ayant de plus grande facilité et qui pourront m'aiguiller.


    La base de donnée concerne des contentieux fait à certains clients, on m'a fourni une liste d'éléments, les voici :



    A partir de cela, j'ai reçu 2,3 conseil d'un ami, il m'a donc conseiller de faire 3 tables

    _ Une table Client ( ID_Client;Nom_Client;Prenom_Client; num_lot)
    _ Une table Contentieux ( ID_conten;#CdtypConten; #ID_Client; ...)
    _ Une table Type Contentieux ( CdtypConten; Nom;...)

    Ce que je n'arrive pas à comprendre, c'est la facon dont on gere les informations concernant un type de contentieux, exemple ( à voir en rapport avec l'image) :
    CdTypConten = 1 = Demande d'engagement de procédure => date édition, transmission traitement, montant dette

    ( mon interrogation porte sur ce que j'ai mis en italique ).



    PS: j'immagine que c'est surement simple pour vous, mais pas tellement pour moi qui ne fait qu'apprendre, et qui ne sais pas encore rouler sans les petites roulettes
    J'espere ne pas avoir etait trop long, et que certains auront le courage de me lire... voir de m'aider

  2. #2
    Responsable Access

    Avatar de Arkham46
    Profil pro
    Inscrit en
    Septembre 2003
    Messages
    5 865
    Détails du profil
    Informations personnelles :
    Localisation : France, Loiret (Centre)

    Informations forums :
    Inscription : Septembre 2003
    Messages : 5 865
    Points : 14 522
    Points
    14 522
    Par défaut
    slt,

    vu que les champs sont peu nombreux tu peux mettre dans la table des contentieux toutes les informations possibles

    ensuite tu adaptes les différents formulaires en fonction du type de contentieux

    per exemple si type = 1 alors il n'y a pas de "réception avocat" donc tu masques ou tu grises le champ

    En résumé c'est à peu près comme ça que je le vois :
    1 - mettre tous les champs possible dans la table
    2 - restreindre l'affichage des formulaires en fonction du type de contentieux

    C'est peut-être pas si simple, ça dépend aussi des différents traitements que tu as a faire sur les données.

    Il faudrait peut-être prévoir une table de paramètrage supplémentaire pour définir par type de contentieux la liste des champs à gérer et éventuellement des codes spécifiants les calculs à faire si ceux-ci différent d'un type de contentieux à l'autre.
    Ceci afin de gérer dynamiquement l'affichage et les traitements, ne pas écrire du code illisible avec des dizaines de IF, et pouvoir éventuellement par la suite rajouter un type de contentieux sans toucher au code.

    Si les traitements ne différent pas trop (le "pas trop" est très subjectif...) d'un type à l'autre c'est faisable.

    Bon courage.

  3. #3
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2006
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 22
    Points : 10
    Points
    10
    Par défaut
    Est-il possible qu'un modérateur déplace mon sujet qui n'a plus sa place dans la section Access, mais plutot dans la section My Sql ou SGBD. Merci au modérateur.

    Bonjour,

    Merci pour la réponse ( que j'avais deja lu ).

    J'ai du temps pour me remettre sur la question, j'ai donc utiliser le logiciel DB designer pour ensuite crée ma base sous MySql.

    Voila un premier jet, pouvez vous me conseillez, m'aiguillez.


  4. #4
    Membre émérite Avatar de Maximil ian
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    2 622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 2 622
    Points : 2 973
    Points
    2 973
    Par défaut
    Salut,

    Pourquoi ne pas faire un schéma entité-association (design conceptuel) au lieu de passer directement aux tables (design logique et physique) ?

    Ca permettrait de mieux dégager ce qui dans la consigne relève de l'entité, de l'association, de la propriété, éventuellement les héritages...
    Pensez au bouton

  5. #5
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2006
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 22
    Points : 10
    Points
    10
    Par défaut
    Alors, j'essaye comme je peux

    Voila un premier jet pour un schéma entité-association :


  6. #6
    Candidat au Club
    Profil pro
    Inscrit en
    Avril 2006
    Messages
    2
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2006
    Messages : 2
    Points : 2
    Points
    2
    Par défaut
    Shellai, mets toujours un Identifiant dans les attributs de tes entités.
    Sinon, tu as reçu un super conseil de maximilian : fignole ton MCD, passe au modèle relationnel et ensuite tu as directement la structure de tes tables et tu ne peux pas te tromper.
    Bon courage
    Béaba

  7. #7
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2006
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 22
    Points : 10
    Points
    10
    Par défaut
    ( je débute, donc je suis pas encore au point au niveau des méthodes à suivre, merci en tout cas pour vos conseils méthodologique )

    J'ai donc mis des identifiants :




  8. #8
    Membre émérite Avatar de Maximil ian
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    2 622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 2 622
    Points : 2 973
    Points
    2 973
    Par défaut
    Le problème c'est que le document est loin d'être clair :

    Pourquoi (date, montant, dette) reviennent tout le temps ?
    Est-ce qu'il faut garder un historique complet de l'évolution des dettes et des procédures engagées concernant chaque contentieux ?
    Y-a-t'il un lien chronologique ou logique entre ces différentes procédures ?

    Autant d'éléments qui vont déterminer le cahier des charges de l'application et à fortiori le modèle de données.
    Je ne sais pas si tu as eu l'opportunité de te faire expliquer plus en détail le système des contentieux et les besoins de la boîte, mais sans une puissante boule de cristal on ne peut objectivement rien construire de valable à partir de ce bout de papier seul...
    Pensez au bouton

  9. #9
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2006
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 22
    Points : 10
    Points
    10
    Par défaut
    Hello,

    Oui en effet désolé c'est loin d'etre explicite pour vous.

    Donc, date, montant, dette.. reviennent constamment, car comme tu la deviné il faut gardé un historique.

    Pour donner un exemple, la liste des contentieux voir 1er document :
    _ Demande d'engagement de procédure
    _ Assignation
    _ ...

    Ses evenements arrivent de facon chronologique, l'un aprés l'autre et on doit garder à chaque évenement la date, le montant de la dette à l'instant t, etc.
    Mais il y'a des exceptions, des évenement dont les informations puissent etre saisie ultérieurement, de facon graphique il faudrait une case grisée qui puisse etre saisisable plus tard.

  10. #10
    Membre émérite Avatar de Maximil ian
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    2 622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 2 622
    Points : 2 973
    Points
    2 973
    Par défaut
    OK. Il reste encore des points obscurs, notamment en ce qui concerne les mises en demeures et les honoraires (peut-il y en avoir plusieurs pour un contentieux ?) mais je pense qu'on peut déjà dégager ces entités :

    - Client
    - Contentieux
    - Evenement

    Le souci semble être de modéliser correctement les différents types d'événements (assignation, audience, saisie...), à ce titre il parait judicieux d'utiliser un héritage.

    Au niveau base de données ça donnerait une table mère événement qui regrouperait les colonnes communes (date, montant, dette) et le type d'événement, ainsi qu'une table fille pour chaque type d'événement spécifique qui ne rentre pas exactement dans ce moule (saisie, recours complémentaire...)

    Cf http://laughingmeme.org/articles/2004/08/14/mysql-and-the-case-for-class-table-inheritance

    http://sqlpro.developpez.com/cours/m...tion/heritage/
    Pensez au bouton

  11. #11
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2006
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 22
    Points : 10
    Points
    10
    Par défaut
    Bonjour,

    J'ai du laisser le projet de coté pendant quelque mois, j'ai maintenant le temps de m'y remettre ( enfin je dois surtout le bouclé pour Septembre...) mais bref.

    Merci pour ton aide Maximilian, j'espere que tu aura un peu de temps à me consacré à nouveau.


    Donc, j'ai suivi les liens que tu as donnée expliquant le principe d'héritage, je pense l'avoir compris.

    Cela dit, ce que je ne comprend pas c'est pourquoi je devrais mettre dans la table evenement à la fois "date, montant dette,..." et aussi le type d'evenement.

    D'aprés ce qu'il me semble avoir compris de la mécanique d'héritage.. il ne faudrait pas plutot mettre le type d'evenement ( par exemple Assignation ou Audience ou Jugement) dans la table Contentieux qui sera fille de la table mere Evenements. ?

  12. #12
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2006
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 22
    Points : 10
    Points
    10
    Par défaut
    up, besoin d'une petite aide pour les tables d'héritage

  13. #13
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2006
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 22
    Points : 10
    Points
    10
    Par défaut
    C'est encore moi...


    Que pensez vous de cela, j'ai utiliser la table Evenement comme table mere de la table fille Contentieux.



    J'ai utilisé le principe d'héritage de sorte à pouvoir repeter à chaque contentieux les evenements date, montant dette..

    Je n'ai biensur pas remplis complétement mes tables.


    J'admet, je patauge un peu pour ma 1ere bdd...

  14. #14
    Membre émérite Avatar de Maximil ian
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    2 622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 2 622
    Points : 2 973
    Points
    2 973
    Par défaut
    Citation Envoyé par Shellai-93
    Cela dit, ce que je ne comprend pas c'est pourquoi je devrais mettre dans la table evenement à la fois "date, montant dette,..." et aussi le type d'evenement.
    C'est une question de commodité, par exemple pour chercher les 3 derniers événements associés à un client.

    Si tu fais une table par type d'événement (assignation, audience, jugement, saisie...) une telle recherche va être fastidieuse. Alors que là il te suffit de chercher dans la table événement les 3 derniers et leur type sera indiqué dans la colonne type.

    Au besoin tu vas ensuite chercher les infos complémentaires dans les tables filles qui héritent d'événement (la donnée "réception avocat" pour un événement de type Assignation par exemple).

    Maintenant tout ne doit pas forcément hériter d'Evénement, ça dépend de ton contexte. Ex : Honoraires n'est pas vraiment un événement, ça peut être une table à part (si 1 contentieux = plusieurs honoraires) ou intégré dans la table contentieux.

    L'héritage ne se situe donc pas entre contentieux et Evenement comme dans ton schéma, mais entre Evénement et des tables d'événements particuliers...
    Pensez au bouton

  15. #15
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2006
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 22
    Points : 10
    Points
    10
    Par défaut
    Hum, je me rend compte à chaque fois à quel point je n'ai pas encore la logique.. base de données.. bon ca viendra!


    Bon, je vais pas faire de schémas inutiles à chaque fois donc j'ai pondu ça:

    Client [#numero_client; Foyer; Nom; Prenom; Lot ]
    Contentieux[#ID_conten; numero_client;
    Evenement[ID_conten; Demande_engagement; Assignation; Audience; ...; Classement_Dossier]
    Date[ID_conten; date; date_edition; date_demande; date_envoie]
    Montant[ID_conten; montant_dette; montant_indeminisation]
    Honoraires [#ID_honoraire; tiers, date_paiement, montant]


    d'aprés ce que tu m'as dit, j'ai essayé de repensé la chose en créant les tables (sur le papier, hein) date et montant qui sont des tables filles de la table evenement.
    Et j'ai crée la table honoraire, qui n'a pas besoin d'hérité de la table evenement.

    Tu peux me dire ce que tu en penses

  16. #16
    Membre émérite Avatar de Maximil ian
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    2 622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 2 622
    Points : 2 973
    Points
    2 973
    Par défaut
    Ce n'est pas tout à fait ça.
    Prenons un exemple simple présenté dans le lien que je t'avais donné :



    Ici, un individu est un type de contact particulier avec des données propres (firstName et lastName) et une organisation est un type de contact particulier possédant un orgName. Individu et organisation héritent de contact.

    Chaque contact occupera donc d'une part une ligne dans la table contact, et d'autre part, selon si c'est un individu ou une organisation, une ligne dans la table individu ou organisation.
    Comment faire le rapprochement entre les deux pour récupérer toutes les données dont on a besoin ? Premièrement la colonne contactType nous indique dans quelle table fille chercher, et deuxièmement un contact déterminé a le même identifiant dans la table Contact et dans Individu ou Organisation.

    Mais on peut aussi très bien imaginer qu'il y ait d'autres colonnes dans la table contact (par exemple : une donnée commune à tous les contacts comme l'email) et que certains contacts restent génériques, ils ne sont ni dans Individu ni dans Organisation et ont seulement ces données de base.

    C'est ce qu'on peut faire avec ton modèle, un truc du genre :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    Evenement (id_evenement, date, montant_dette, type_evenement)
     
    Assignation (id_evenement, reception_avocat)
    RecoursConmplementaire (id_evenement, montant_indemnisation)
    RecoursContentieux (id_evenement, montant_indemnisation)
    ...
    Bref tous les événements qui ont autre chose que les colonnes de base Date et Montant_dette (ce sont les colonnes qui reviennent le plus, celles qu'on peut "factoriser') sont déclinés dans des tables filles qui héritent de Evenement...

    C'est plus clair ?
    Pensez au bouton

  17. #17
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2006
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 22
    Points : 10
    Points
    10
    Par défaut
    Ouais c'est plus clair merci, c'est pas que c'était pas clair avant, juste que j'avais mal compris la facon de procéder ( rassembler les entités identiques )

    Donc, ca me donnerait ça, si j'ai bien compris :

    Client(#numero_client, Foyer, Nom, Prenom, Lot)
    Contentieux(#ID_conten; numero_client) (J'ai un point d'ombre concernant l'utilité/fonction de cette table.. et comment la remplir)

    Evenement (#id_evenement, date, montant_dette, type_evenement)
    Demande_eng_proc (id_evenement, transmission, traitement)
    Assignation (id_evenement, reception_avocat)
    Recours_comp (id_evenement, montant_indemnisation)
    Recours_contentieux (id_evenement, montant_indemnisation)
    Indemnisation (id_evenement, montant_indemnisation)
    Imputation_art700 (id_evenement, references)
    Autres_imputations (id_evenement, references)



    Concernant la partie que j'ai mis en marron, donc comme ton exemple du contact, là ce qui permettra de savoir si il faut aller dans telle ou telle table fille ca sera l'attribu "type_evenement" de la table mere Evenement...?
    Mais dans le cas où c'est un evenement comme Audience qui ne fait pas appel à une table fille, comment on le gere...? on va simplement remplir le champs type_evenement qui ne sera donc pas le nom d'une des tables filles.. et il saura qu'il a pas besoin "d'aller plus loin" ?

    Enfin j'imagine que ça, je devrais le gerer lors de la programmation sql...?



    En tout cas merci pour tes explications, j'apprend beaucoup, j'aurai pas eu cette patience avec un boulet comme moi



    Edit: ah oui, je voulais également te demander si il n'était donc pas possible de rassembler les tables filles suivantes :

    Recours_comp (id_evenement, montant_indemnisation)
    Recours_contentieux (id_evenement, montant_indemnisation)
    Indemnisation (id_evenement, montant_indemnisation)

    &

    Imputation_art700 (id_evenement, references)
    Autres_imputations (id_evenement, references)


    Ne pourrais-je pas y ajouter un attribut comme type_evenement, simplement pour préciser si c'est par exemple un recours complémentaire ou un recour contentieux ?

    Donc :

    Indemnisation ( id_evenement, montant_indemnisation, type_evenement2)
    &
    Reference( id_evenement, references, types_evenement3)

  18. #18
    Membre émérite Avatar de Maximil ian
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    2 622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 2 622
    Points : 2 973
    Points
    2 973
    Par défaut
    Citation Envoyé par Shellai-93
    Donc, ca me donnerait ça, si j'ai bien compris :

    Client(#numero_client, Foyer, Nom, Prenom, Lot)
    Contentieux(#ID_conten; numero_client) (J'ai un point d'ombre concernant l'utilité/fonction de cette table.. et comment la remplir)

    Evenement (#id_evenement, date, montant_dette, type_evenement)
    Demande_eng_proc (id_evenement, transmission, traitement)
    Assignation (id_evenement, reception_avocat)
    Recours_comp (id_evenement, montant_indemnisation)
    Recours_contentieux (id_evenement, montant_indemnisation)
    Indemnisation (id_evenement, montant_indemnisation)
    Imputation_art700 (id_evenement, references)
    Autres_imputations (id_evenement, references)
    Exactement. La table contentieux est là tout simplement parce qu'il peut y avoir plusieurs contentieux par client (enfin, j'imagine) et qu'à un contentieux se rattachent plusieurs événements. Donc tu peux ajouter une clé étrangère id_contentieux à la table événement.

    Citation Envoyé par Shellai-93
    Concernant la partie que j'ai mis en marron, donc comme ton exemple du contact, là ce qui permettra de savoir si il faut aller dans telle ou telle table fille ca sera l'attribu "type_evenement" de la table mere Evenement...?
    Mais dans le cas où c'est un evenement comme Audience qui ne fait pas appel à une table fille, comment on le gere...? on va simplement remplir le champs type_evenement qui ne sera donc pas le nom d'une des tables filles.. et il saura qu'il a pas besoin "d'aller plus loin" ?
    Oui. Par exemple un jugement aura come type d'événement "Jugement" et cela permettra de savoir si l'affaire est déjà passée en jugement, éventuellement combien de fois... (après je ne connais pas les détails de la procédure)

    Citation Envoyé par Shellai-93
    Edit: ah oui, je voulais également te demander si il n'était donc pas possible de rassembler les tables filles suivantes :

    Recours_comp (id_evenement, montant_indemnisation)
    Recours_contentieux (id_evenement, montant_indemnisation)
    Indemnisation (id_evenement, montant_indemnisation)

    &

    Imputation_art700 (id_evenement, references)
    Autres_imputations (id_evenement, references)


    Ne pourrais-je pas y ajouter un attribut comme type_evenement, simplement pour préciser si c'est par exemple un recours complémentaire ou un recour contentieux ?
    Si tu sens que ces événements sont de même nature, pourquoi pas, mais 2 niveaux d'héritage ça va compliquer les requêtes. Il vaut peut-être mieux commencer par plus simple...
    Pensez au bouton

  19. #19
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2006
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 22
    Points : 10
    Points
    10
    Par défaut
    Ok pour la table contentieux, c'est capish.

    Concernant le 2nd niveau d'héritage, dans ce cas je vais laisser tel quel alors, j'ai pas spécialement d'interet à regrouper les tables finalement, et si ca simplifie les requetes, on va laisser comme ça

    En reprennant tout du début, j'en arrive donc à cela, niveau MCD :

    En fait, j'ai un gros doute sur les cardinalités...
    _ De client à contentieux : 1,n car un client peut avoir 1 ou plusieurs contentieux en cours
    _ De contentieux à client : 1,1 car un contentieux ne peux etre identifié qu'a un seul client...?
    _ De contentieux à Evenement : 1,n car d'un contentieux peux resulter plusieurs evenements
    _ D'Evenement à contentieux : 1,n, car un evenement peut etre applicable à different contentieux


  20. #20
    Membre émérite Avatar de Maximil ian
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    2 622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 2 622
    Points : 2 973
    Points
    2 973
    Par défaut
    Citation Envoyé par Shellai-93
    _ De client à contentieux : 1,n car un client peut avoir 1 ou plusieurs contentieux en cours
    Oui.
    Citation Envoyé par Shellai-93
    _ De contentieux à client : 1,1 car un contentieux ne peux etre identifié qu'a un seul client...?
    Ca je n'en sais rien, c'est une règle de gestion qui dépend de ton contexte
    Citation Envoyé par Shellai-93
    _ De contentieux à Evenement : 1,n car d'un contentieux peux resulter plusieurs evenements
    Oui.
    Citation Envoyé par Shellai-93
    _ D'Evenement à contentieux : 1,n, car un evenement peut etre applicable à different contentieux
    Encore une fois, c'est à toi de le déterminer. Est-ce qu'une seule saisie peut concerner plusieurs dossiers en cours, est-ce qu'un jugement peut porter sur plusieurs affaires ? ...
    Pensez au bouton

Discussions similaires

  1. Création d'une bdd sous powerAMC
    Par yoaneca dans le forum UML
    Réponses: 0
    Dernier message: 20/06/2012, 13h01
  2. Besoin d'aide sur la création d'une page Web
    Par FournelAlex dans le forum Général Conception Web
    Réponses: 2
    Dernier message: 21/01/2011, 18h37
  3. aide sur la création d'une BD
    Par missdev dans le forum Accès aux données
    Réponses: 4
    Dernier message: 27/07/2009, 20h36
  4. Réponses: 9
    Dernier message: 30/04/2008, 11h54
  5. Questions sur la création d'une BDD en SQL (débutant)
    Par CleeM dans le forum Langage SQL
    Réponses: 10
    Dernier message: 14/06/2007, 16h14

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