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

VB.NET Discussion :

méthodologie base de données


Sujet :

VB.NET

  1. #1
    Membre régulier
    Homme Profil pro
    Étudiant
    Inscrit en
    Mars 2012
    Messages
    161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Biens de consommation

    Informations forums :
    Inscription : Mars 2012
    Messages : 161
    Points : 103
    Points
    103
    Par défaut méthodologie base de données
    Bonjour,

    Je travaille actuellement à la création d'un petit programme en vb avec visual basic express 2010. Apres avoir appris à utiliser le langage visual basic par excel je m'attaque à son apprentissage sans excel donc sans une base de donnée accessible par l’appelle de feuille et de cellule mais par une base de donnée à partir de sql microsoft server 3.5.

    La logique n'est donc pas la même, avec excel je faisais ma base de donnée avec des tableaux à double entré sur des feuilles et je faisais mes calculs de manière automatiques avec des fonctions excel sur les tableaux, je récupérais ensuite les données dont j'avais besoin en appelant les feuilles et les cellules avec des macros.

    En base de données SQL je dois faire des tables, les liées etc, je n'ai donc pas les connaissances techniques pour le moment. En parcourant beaucoup de tuto, de cours etc j'ai trouvé comment intégré des tables de données les fonctions utilisateurs, les remplir etc les fonctions simple dont j'ai besoin en local mais il me manque quelque chose de plus important encore à savoir la méthodologie logique. J'ai donc décidé de laisser tomber le coté technique et de prendre au préalable un stylo et une feuille pour modéliser mes info et faire mes tables.

    Alors j'ai regarder pas mal de tuto sur la méthodologie et si je pense avoir compris le principe mais je n'arrive pas à l'adapter à mon problème.

    La plupart des tuto vont donner des exemples simple par exemple la méthode MERISE, je transforme un film en dvd et celui ci va être louer par un ou plusieurs clients. Ce qui nous donne 4 tables (film,transformer, dvd, clients). Jusque la c'est assez logique.

    Je me retrouve confronté à un problème car je veux modéliser le résultat de matchs de foot de ligue 1. J'ai donc posé 3 tables:

    "EQUIPES DOM" avec comme attributs (id_equipe_dom, nom equipe)
    "EQUIPES EXT" avec comme attributs (id_equipe_ext, nom equipe)
    "JOUER" table de relation avec comme attribut(id_equipe_dom, id_equipe_ext)

    Voila maintenant comment puis je faire pour avoir les données "RÉSULTAT" avec comme attributs (victoire, nul, défaite)? Je n'arrive pas à voir comment organiser et lier les données sur le papier car si dans l'exemple du DVD l'action est d'abord de copier le film sur le dvd puis de louer le dvd. Dans mon programme le résultat vient de la liaison JOUER, ou alors il faudrait que je lie la table de liaison JOUER à la table RESULTAT. J'ai l'impression de m y perdre et de mal m y prendre.

    Auriez vous des idées d'organisation, je pense que je n'ai plus le recul nécessaire ou que je m'y suis mal pris à la base, une petite aide pour me remettre les idées en place serai très bien venue car la je bloque (et je n'en suis qu'au papier ;/ )

    Merci d'avance. Cordialement

  2. #2
    Membre émérite Avatar de mactwist69
    Homme Profil pro
    Développement VB.NET
    Inscrit en
    Janvier 2007
    Messages
    1 707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Saône et Loire (Bourgogne)

    Informations professionnelles :
    Activité : Développement VB.NET
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 707
    Points : 2 528
    Points
    2 528
    Par défaut
    Bonjour,

    Très bonne initiative de se poser des questions avant d'attaquer le code.

    La méthode Merise est bien pour modéliser, mais au début c'est parfois dur de comprendre les besoins. C'est avec l'expérience qu'on voit vite ce dont on a besoin.


    Sur l'exemple du DVD, pareil :
    - une table film (id, nom etc.)
    - une table dvd (id, id_film etc.)
    - une table client (id, nom)
    - et une table location (id, id_dvd, id_client, date etc.)

    En gros il y a les tables contenants des entités (film, dvd, equipe etc)
    et les tables "d'opérations" tel que les matches ou la locations.



    Sur ton exemple, je te donne mon point de vue :

    Deux tables suffisent :

    Une table unique Equipe (id, nom, etc...)
    Une table Match (id unique, equipe_domicile, equipe_exterieur, resultat, date etc...)

    Où equipe_domicile pointe sur une equipe et equipe_exterieur pointe aussi sur une equipe.

    Il te suffira par la suite de travailler sur la table match pour ressortir tes résultats, avec deux jointure sur la table équipe pour faire ressortir le nom plutôt que l'identifiant de l’équipe qui est stocké dans match.
    L'avenir appartient à ceux... dont les ouvriers se lèvent tôt. (Coluche)

  3. #3
    Membre actif
    Homme Profil pro
    Developpeur
    Inscrit en
    Février 2013
    Messages
    180
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Developpeur

    Informations forums :
    Inscription : Février 2013
    Messages : 180
    Points : 271
    Points
    271
    Par défaut
    Bonjour,
    +1 tu as de bonne initiative

    permet moi d'éclaircir quelque terme (ça me semblait confus en lisant ton poste)
    vb = Visual basic (très très vieux)
    développement sur excel = VBA
    développement sur visual studio est du .NET (VB.NET ou C# pour le principal)
    Donc tu as appris a développer avec du VBA et maintenant tu passe sur du VB.NET
    et tu t'attaque à la liaison entre ton programme et tes données,
    c'est bien ça ?

    Alors navrer d'avoir à t’annoncer ça mais le VBA et le VB.NET sont trèèèèèèèèèèès différent, à part la syntaxe.
    le VB.NET est vraiment plus puissant.

    ensuite t'a demande est de récupérer des données, et comme tu as l'air d'être curieux, je ne te donnerai pas de code, se ne serait pas te rendre service
    mais ce que tu cherche à faire est du SQL (langage de base de données)
    donc en reprenant les table que tu as cité
    t'as table Résulatat doit être une conténation de tes match jouer
    pour ça tu doit modifier tes table et ensuite grâce à une requete SQL tu obtient t'es résultat

    "EQUIPES" avec comme attributs (id_equipe, nom equipe, victoire, defaite, null)
    "JOUER" table de relation avec comme attribut(id_jouer, id_equipe_ext, id_equipe_dom, id_resultat)
    "RESULTAT" (id_resultat, score_equipe_ext, score_equipe_dom)

    voila un exemple de tes tables, ce n'est pas optimal mais je ne sais pas vraiment la finalité de tout ça, donc on peut s'en contenter
    et pour finir il reste a créer la requête SQL, la je te laisse apprendre le SQL ce n'est pas très compliqué

    Cordialement, Et bon courage

  4. #4
    Membre émérite Avatar de mactwist69
    Homme Profil pro
    Développement VB.NET
    Inscrit en
    Janvier 2007
    Messages
    1 707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Saône et Loire (Bourgogne)

    Informations professionnelles :
    Activité : Développement VB.NET
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 707
    Points : 2 528
    Points
    2 528
    Par défaut
    Si chaque enregistrement de Résultat correspond forcement 1 et 1 seul enregistrement de Jouer,
    alors pourquoi faire deux tables ?

    Avec le risque d'avoir un enregistrement Jouer sans Résultat ou inversement...

    Pour moi c'est l'exemple type d'une complication du modèle sans utilité. (rien de personnel )

    On essai trop souvent dans les modélisations de réduire les tables au minimum, avec pour conséquence d'en avoir beaucoup trop pour rien.

    Pour moi il vaut mieux une table de 50 colonnes, que 25 tables de 2 colonnes. Je vous raconte pas les jointures après.

    (A moins que les tables possèdent énormément de colonnes (+100) et/ou avec beaucoup d'enregistrements, genre plusieurs millions).
    L'avenir appartient à ceux... dont les ouvriers se lèvent tôt. (Coluche)

  5. #5
    Membre actif
    Homme Profil pro
    Developpeur
    Inscrit en
    Février 2013
    Messages
    180
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Developpeur

    Informations forums :
    Inscription : Février 2013
    Messages : 180
    Points : 271
    Points
    271
    Par défaut
    Citation Envoyé par mactwist69 Voir le message
    Pour moi il vaut mieux une table de 50 colonnes, que 25 tables de 2 colonnes.
    je suis 100 % d'accord, cela évite d'avoir aussi des doublon de données, après ce n'est qu'une interprétation de ce qu'il a exposé
    après tout dépend de la flexibilité de l'application et de son importance.
    le model que j'ai cité est valable dans de petite application, mais certainement pas pour une application qui enregistre des millions de données,
    et ce n'est pas une mauvaise chose de faire des table multiple

  6. #6
    Membre régulier
    Homme Profil pro
    Étudiant
    Inscrit en
    Mars 2012
    Messages
    161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Biens de consommation

    Informations forums :
    Inscription : Mars 2012
    Messages : 161
    Points : 103
    Points
    103
    Par défaut
    Merci pour vos réponses. Effectivement je m'y prend certainement mal mais j'essaye de comprendre le fonctionnement des bases de données et comment je pourrai les optimiser pour les besoins de mon petit logiciel.

    Pour comprendre les bases de données j'utilise ce tuto que je trouve super bien fait et pour le coup tres ludique :


    Mes besoins en fait ne sont pas très compliqué je pense.

    En gros je fais un petit programme d'optimisation de pari sportif. Je l'ai fait sur excel et je veut le faire en vb.net maintenant donc je reprend quasiment à 0 .

    Clairement j'ai mes équipes donc en ligue 1 il y'en a 20 chaque équipe rencontres chaque équipe donc 19 confrontations aller et 19 confrontations retour pour chaque équipe
    A chaque match il y'a une équipe domicile et une équipe extérieur

    Mon tableau sur excel se présenter comme ça j'avais un fichier du nom de l'équipe et dedans un tableau de donnée avec:
    colonne 1 equipe exterieur
    colonne 2 buts 0-15mn
    colonne 3 buts 16-30mn
    colonne 4 buts 31-45mn
    etc....

    Cela me donner des stat, resultat à la mi temps, resultat fin de match, min 1er but marqué etc

    Donc l'idée c'est que l'utilisateur choisisse equipe dom dans une listbox puis l'équipe ext dans une autre listbox puis qu'il clique sur ok
    ça l'enverrai vers une form avec un datagriedview dans lequel il y'aurai en colonne 1 l'équipe dom en colonne 2 l'équipe ext puis colonne 3 0-15mn etc... puis enregistrer les données

    Exemple si Lens-Paris
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
                                                                              BUTS DOM                                                                              BUTS EXT                            
    équipe dom   équipe ext    0-15mn     16-30mn      31-45mn       45-60mn    61-75mn       76-90mn        0-15mn          16-31mn        etc....
        Lens            Paris           1                                                                   1                                                           1
    Voila, dans mon exemple Lens marque 1 but entre la 0-15mn et 1 but entre la 61 et 75mn et Paris marque entre la 16-31mn
    Avec ces infos que ça me fasse des stats

    Donc dans l'idée il faudrait que j'ai une table "equipe" que j'ai une table "lens domicile" que j'ai une table "resultat" que j'ai une table et une table "paris exterieur"

    Dans mon exemple la table résultat serai une table de laison, qui enregistrerai equipe _dom = 2 et equipe_ext = 1, dans ma table "equipe" j'aurai "equipe_dom" =V et "equipe_ext" = D etc.. vous comprenez ma logique (j’espère)

    Donc le but serai que lorsque je clique sur "lens domicile "dans mon programme, ça me transcrive dans un tableau : / victoire = 100% / nul = 0% / défaite = 0%

    Voila mon rpobleme ne se trouve pas encore dans le code (ca c'est encore un autre micmac ) mais dans l'organisation de mes tables déjà au préalable...Je souffre

  7. #7
    Membre émérite Avatar de mactwist69
    Homme Profil pro
    Développement VB.NET
    Inscrit en
    Janvier 2007
    Messages
    1 707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Saône et Loire (Bourgogne)

    Informations professionnelles :
    Activité : Développement VB.NET
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 707
    Points : 2 528
    Points
    2 528
    Par défaut
    Avoir une table Lens_dom... et donc une table Lens_exterieur...

    Donc si tu fais ça pour toutes les équipe tu auras : 40 tables ?
    Il y a un problème.

    Si le modèle est bien fait, avec 3 à 5 tables tu t'en sors.

    Une table equipe : (id, nom)
    une table match (id_match, id_equip_dom, id_equip_ext, nb_but_dom, nb_but_ext)


    Et pour avoir un résultat détaillé des buts, une table but :
    but (id_but, id_match, id_equipe, Heure du but).

    Du coup avec cette table on a d'ailleurs plus besoin de nb_but_dom et nb_but_ext de la table match... Car dans la requete, tu additionnera les buts pour avoir le résultat... MAis bon, déjà comme ça)

    Avec ceci, en faisant une requête (et 2 paramètres), tu as tout ce que tu veux.
    Exemple :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    Select * from Match
    Inner join equipe as equipe_dom on equipe_dom.id = Match.id_equip_dom
    Inner join equipe as equipe_ext on equipe_ext.id = Match.id_equip_ext
    Inner join but on but.id_match = Match.id
     
    Where equipe_dom.nom = 'Lens' AND equipe_ext.nom = 'Paris'

    Tandis qu'avec ta solution des 40 tables... Tu devras écrire, 80 requêtes différentes, vu qu'il y a 80 combinaisons de matchs :
    J'essai de faire une requête sur ton modele :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    Select * from resultat
    inner join LEns_dom on LEns_dom.id = resultat.equipe_dom
    inner join equipe as equipe_dom on equipe_dom.id_equipe = LEns_dom.id_equipe
    inner join PAris_ext on PAris_ext .id = resultat.equipe_ext
    inner join equipe as equipe_ext on equipe_ext.id_equipe = PAris_ext.id_equipe
    Tu vas devoir changer cette requête, pour qu'à chaque fois, les noms de tables correspondent au noms de equipes...

    Tandis qu'avec l'autre solution, tu n'as que le paramètres à changer...

    C'est une erreur de vouloir designer les tables pour qu'elles correspondent au résultat : en l’occurrence tu es motivés par les statistiques des matches à domiciles.

    Avec la solution générique présentée, c'est avec une requête que tu va obtenir ce que tu veux :
    Requêtes sur les matchs gagnés par Lens à domicile ? Facile :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    Select * from Match
    Inner join equipe as equipe_dom on equipe_dom.id = Match.id_equip_dom
    Inner join but on but.id_match = Match.id
     
    Where equipe_dom.nom = 'Lens' AND Match.nb_but_dom > Match.nb_but_ext
    L'avenir appartient à ceux... dont les ouvriers se lèvent tôt. (Coluche)

  8. #8
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    Hello,

    Les bases de données et leur modélisation étant un domaine que j'adore et qui me tiens à coeur, je me dois d'intervenir...

    Déjà, je voudrais revenir sur un truc que mactwist a écrit :
    On essai trop souvent dans les modélisations de réduire les tables au minimum, avec pour conséquence d'en avoir beaucoup trop pour rien.
    Pour moi il vaut mieux une table de 50 colonnes, que 25 tables de 2 colonnes. Je vous raconte pas les jointures après.
    (A moins que les tables possèdent énormément de colonnes (+100) et/ou avec beaucoup d'enregistrements, genre plusieurs millions)
    Je ne suis pas trop d'accord. Dans 99,9% des cas, si une table fait plus de 15 colonnes (et encore, je suis large), c'est qu'il y a un problème de modélisation.

    Cela étant dit, il y a une chose qui n'a pas été vraiment dite jusqu'ici. Pour modéliser correctement une base de données avec la méthode Merise, on commence par établir le MCD (Modèle Conceptuel de Données). Or, pour établir ce MCD, il faut commencer par définir les entités-types et les règles de gestion qui les régissent.

    Plus de détails sur la méthode Merise dans l'ouvrage de Michel Divine "Parlez-vous Merise" qui est très bien (mis à part la partie sur le MPD).

    Cela étant dit, pour pouvoir définir les entités-types et leurs règles de gestion, il faut d'abord définir clairement les besoins fonctionnels. Bien souvent, les entités-types en ressortent naturellement. De ces besoins, les noms communs composeront les entités-types et les verbes (actions) les relations entre ces entités-types.

    De ce que j'ai lu, les besoins sont :
    • Pouvoir définir les équipes --> entité-type EQUIPE
    • Faire jouer un match entre 2 équipes --> relation JOUER UN MATCH
    • Lister les buts --> entité-type BUT


    Une fois cela fait, la définition des règles de gestion en devient plus simple. Une règle de gestion est une phrase définissant une relation entre deux entités-types.
    Le cas des équipes jouant des matches étant un peu spécial (car il va s'agir d'une relation réflexive avec une cardinalité n;n), je vais prendre un cas d'école qui est la gestion de factures.

    Pour gérer les factures de ma compagnie de plomberie Dupont & Fils, je vais avoir besoin des entités-types CLIENT, FACTURE, LIGNE_DE_FACTURE (et je simplifie) et les règles de gestion seront les suivantes :
    • Une CLIENT peut RECEVOIR plusieurs factures et une FACTURE est RECUE par un (et un seul) CLIENT.
    • Une FACTURE CONTIENT une ou plusieurs LIGNES et une LIGNE est CONTENUE par une (et une seule) FACTURE.


    Pour une bonne écriture des règles de gestion, reportez-vous à ce billet de blog de Cinéphil.
    J'ai mis les mots clef en majuscule. Maintenant, à l'aide d'un logiciel de modélisation (ou d'un crayon et d'une feuille de papier mais ça, j'peux pas le mettre en pièce jointe), voici ce que donnent ces règles de gestions : (j'ai utilisé JMerise qui est disponible gratuitement)
    Nom : client.jpg
Affichages : 334
Taille : 124,0 Ko (j'espère que ce sera visible et que je n'ai pas inversé les cardinalités sur le dessin... Vu que je travaille seul mes erreurs restent "logique" pour moi et personne n'est là pour me corriger^^)

    Les rectangles sont les entités-types et les ovales les relations. J'ai donc simplement repris les règles de gestion et je l'ai transposées sous forme schématisée. C'est ce qu'on appelle le MCD. Mais il est loin d'être complet !! Il manque ici les attributs des entités-types (pour un client, son nom, prénom, adresse, etc) et leur clef primaire (et les éventuelles clefs alternatives).

    Je vous laisse déjà assimiler ceci, nous proposer une premier jet de MCD pour vos équipes et leurs matches et nous ferons la suite ensuite.

    N.B. : On pourrait facilement ajouter la notion de DIVISION car en fin de saison, il y a des équipes qui montent et des équipes qui descendent. Cela pour être sympa de le gérer.
    N.B.2 : Cette discussion aurait plus sa place sur le forum merise ou schéma où vous auriez de vrais experts de la modélisation dont notamment fsmrel qui est, pour moi, LA référence en terme de modélisation de notre forum (et de qui j'ai tout appris ou presque).
    Images attachées Images attachées  
    Kropernic

  9. #9
    Membre émérite Avatar de mactwist69
    Homme Profil pro
    Développement VB.NET
    Inscrit en
    Janvier 2007
    Messages
    1 707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Saône et Loire (Bourgogne)

    Informations professionnelles :
    Activité : Développement VB.NET
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 707
    Points : 2 528
    Points
    2 528
    Par défaut
    Hello Kropernic,

    Je ne suis pas trop d'accord. Dans 99,9% des cas, si une table fait plus de 15 colonnes (et encore, je suis large), c'est qu'il y a un problème de modélisation.
    Absolument pas d'accord avec cette affirmation...
    Si pour une entité on a 75 informations distinctes et systématiques, alors il faudra 75 colonnes.
    L'avenir appartient à ceux... dont les ouvriers se lèvent tôt. (Coluche)

  10. #10
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    Citation Envoyé par mactwist69 Voir le message
    Hello Kropernic,



    Absolument pas d'accord avec cette affirmation...
    Si pour une entité on a 75 informations distinctes et systématiques, alors il faudra 75 colonnes.
    Si, tu as ça, effectivement. Cependant, je n'ai encore jamais rencontré ce cas. As-tu un exemple ?
    Kropernic

  11. #11
    Membre émérite Avatar de mactwist69
    Homme Profil pro
    Développement VB.NET
    Inscrit en
    Janvier 2007
    Messages
    1 707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Saône et Loire (Bourgogne)

    Informations professionnelles :
    Activité : Développement VB.NET
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 707
    Points : 2 528
    Points
    2 528
    Par défaut
    Pas besoin d'exemple j'ai envie de dire, c'est le raisonnement qui ne va pas : Ce n'est pas au nombre de colonne que l'on voit si un modele est mal fait, c'est impossible de juger juste avec ça.

    J'ai au contraire le principe inverse : Si j'ai une table T1 pour laquelle 1 ligne = 1 personne et une table T2 où 1 ligne = 1 personne
    Et si dans le code, on est amené à faire des jointure entre T1 et T2, alors c'est que T1 et T2 devraient être fusionnés...

    Prenons un exemple simple qui va porter à débat :

    Une table personne (nom, prenom, date de naissance)
    une table adresse (7 colonnes d'adresses)

    Pour moi il faut les fusionner.

    Pourquoi faire des jointures inutiles ?
    L'avenir appartient à ceux... dont les ouvriers se lèvent tôt. (Coluche)

  12. #12
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    Citation Envoyé par mactwist69 Voir le message
    Pas besoin d'exemple j'ai envie de dire, c'est le raisonnement qui ne va pas : Ce n'est pas au nombre de colonne que l'on voit si un modele est mal fait, c'est impossible de juger juste avec ça.

    J'ai au contraire le principe inverse : Si j'ai une table T1 pour laquelle 1 ligne = 1 personne et une table T2 où 1 ligne = 1 personne
    Et si dans le code, on est amené à faire des jointure entre T1 et T2, alors c'est que T1 et T2 devraient être fusionnés...

    Prenons un exemple simple qui va porter à débat :

    Une table personne (nom, prenom, date de naissance)
    une table adresse (7 colonnes d'adresses)

    Pour moi il faut les fusionner.

    Pourquoi faire des jointures inutiles ?
    On devrait p-e continuer ce débat en mp pour ne pas polluer la discussion mais d'un autre côté, cela peut être intéressant pour d'autres...

    Pour ton exemple personne-adresse, il ne faut surtout pas les fusionner ! Comment feras-tu lorsqu'une personne aura plusieurs adresses ? Typiquement, un client aura une adresse de facturation et de livraison qui peuvent être différentes. Il faudrait donc ajouter 2 tables. Une pour lister les types d'adresse possibles (on pourrait ajouter une adresse pour le courrier par exemple) et une seconde pour faire la jointure entre les types d'adresse et les adresses car une adresse possède au moins un type (cardinalité 1,n) et un type peut être possédé par plusieurs adresses (cardinalité 0,n).

    Après bien sûr, ici je parle du cas d'école. Si pour ton business tu ne t'inquiètes que d'un seul type d'adresse et que tu es certain que cela ne changera jamais, alors tu peux éventuellement fusionner les deux tables. Cependant, je ne suis pas devin et ne peux prévoir l'avenir. Je préférerai donc toujours laisser les tables séparées pour avoir le moins de changement à faire le cas échéant. Surtout que si cela te gêne vraiment d'avoir à écrire une jointure, il te suffit de créer une vue pour ne plus à avoir à t'en préoccuper.

    EDIT : Concernant l'histoire des 75 colonnes, d'un point de vue purement théorique, une entité-type avec 75 attributs peut être valide. D'un point de vue pratique, je serais vraiment curieux d'en avoir un exemple.
    Kropernic

  13. #13
    Membre émérite Avatar de mactwist69
    Homme Profil pro
    Développement VB.NET
    Inscrit en
    Janvier 2007
    Messages
    1 707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Saône et Loire (Bourgogne)

    Informations professionnelles :
    Activité : Développement VB.NET
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 707
    Points : 2 528
    Points
    2 528
    Par défaut
    Oui je pense qu'on devrait discuter un peu plus par mp

    Sur l'exemple tout de même, bien sur que dans mon exemple, on part du principe qu'il n'y a qu'une adresse.

    Mais même si il peut avoir deux ou trois adresses, on peut très bien faire le choix de mettre ces trois adresses dans la table client...

    Car si on partait de deux adresses et qu'il en faut une troisième... Soit tu ajoutes 7 colonnes à la table client, soit tu crées une autre table... mais il faudra ajouter de toute façon la clé étrangère dans la table client.
    Au niveau mise à jour, tu auras quasi le même travail à faire...

    Donc la question se pose bien en terme de Stockage et non pas Objet.

    Et rien n'empêche dans le code d'avoir une objet "adresse" tout cours...

    Et un exemple pratique : En ce moment je travail dans l'industrie, on suit des produits qui ont bien une cinquantaine de caractéristiques techniques. Tous dans la même table.

    - Et comme dans les requêtes on ne ramène que les colonnes qu'on a décidé, le nombre de colonne n'influe pas sur le résultat. Voir on améliore les performances dans le cas où on aurait eu deux tables, on aurait dû faire des jointures...

    - autre point positif, on s'assure qu'il n'y a pas de produit sans caractéristique.
    L'avenir appartient à ceux... dont les ouvriers se lèvent tôt. (Coluche)

  14. #14
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    Citation Envoyé par mactwist69 Voir le message
    Oui je pense qu'on devrait discuter un peu plus par mp

    Sur l'exemple tout de même, bien sur que dans mon exemple, on part du principe qu'il n'y a qu'une adresse.

    Mais même si il peut avoir deux ou trois adresses, on peut très bien faire le choix de mettre ces trois adresses dans la table client...

    Car si on partait de deux adresses et qu'il en faut une troisième... Soit tu ajoutes 7 colonnes à la table client, soit tu crées une autre table... mais il faudra ajouter de toute façon la clé étrangère dans la table client.
    Au niveau mise à jour, tu auras quasi le même travail à faire...

    Donc la question se pose bien en terme de Stockage et non pas Objet.

    Et rien n'empêche dans le code d'avoir une objet "adresse" tout cours...

    Et un exemple pratique : En ce moment je travail dans l'industrie, on suit des produits qui ont bien une cinquantaine de caractéristiques techniques. Tous dans la même table.

    - Et comme dans les requêtes on ne ramène que les colonnes qu'on a décidé, le nombre de colonne n'influe pas sur le résultat. Voir on améliore les performances dans le cas où on aurait eu deux tables, on aurait dû faire des jointures...

    - autre point positif, on s'assure qu'il n'y a pas de produit sans caractéristique.
    Je continue cette discussion en MP
    Kropernic

  15. #15
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    Février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : Février 2010
    Messages : 3 611
    Points : 9 743
    Points
    9 743
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par mactwist69 Voir le message
    Absolument pas d'accord avec cette affirmation...
    Si pour une entité on a 75 informations distinctes et systématiques, alors il faudra 75 colonnes.
    Je rejoins Kropernic pour le coup, 75 colonnes il y a un problème de modélisation quelque part. Même sur des objets financiers par exemple, on peut se retrouver avec des centaines de tables pour construire un objet mais il faut à tout prix éviter les tables obèses surtout si la volumétrie est importante. SQLPro a écrit un article intéressant sur le sujet : Base de données et performances… petites tables et tables obèses !

    A partir de 20 colonnes on parle déjà de table obèse, et j'ai pu constater ce phénomène en vrai sur Oracle. Certes le projet n'avait rien à voir avec celui-ci, mais les DBA et les clients n'étaient pas contents

    Il vaut mieux avoir des relations (1:1) (= segmentation verticale) qu'une table obèse. On peut faire de la segmentation verticale par exemple dans le cas où on a certaines colonnes auxquelles on accède plus fréquemment. Le chargement de ces colonnes sera alors plus rapide, puisque non ralenti par la masse des autres colonnes.
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  16. #16
    Membre émérite Avatar de mactwist69
    Homme Profil pro
    Développement VB.NET
    Inscrit en
    Janvier 2007
    Messages
    1 707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Saône et Loire (Bourgogne)

    Informations professionnelles :
    Activité : Développement VB.NET
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 707
    Points : 2 528
    Points
    2 528
    Par défaut
    Très intéressant cet article.

    Ça fait pas de mal d'avoir une petite piqûre de rappel sur des principes qu'on ne devrait pas oublié.

    Ce qui me confirme, hélas, que partout où j'ai travaillé, c'est vraiment une catastrophe au niveau des bases de données...
    Projets pilotés par des "développeurs-hyper-pointus-que tu-peux-pas-teste"...
    L'avenir appartient à ceux... dont les ouvriers se lèvent tôt. (Coluche)

  17. #17
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    Citation Envoyé par mactwist69 Voir le message
    Très intéressant cet article.

    Ça fait pas de mal d'avoir une petite piqûre de rappel sur des principes qu'on ne devrait pas oublié.

    Ce qui me confirme, hélas, que partout où j'ai travaillé, c'est vraiment une catastrophe au niveau des bases de données...
    Projets pilotés par des "développeurs-hyper-pointus-que tu-peux-pas-teste"...
    Déménage en belgique et vient travailler avec moi, on va bientôt probablement engager (faut parler flamand par contre^^)
    Kropernic

  18. #18
    Membre émérite Avatar de mactwist69
    Homme Profil pro
    Développement VB.NET
    Inscrit en
    Janvier 2007
    Messages
    1 707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Saône et Loire (Bourgogne)

    Informations professionnelles :
    Activité : Développement VB.NET
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 707
    Points : 2 528
    Points
    2 528
    Par défaut
    Tu vas rire... Mes ceux dont je parle, SONT DES BELGES !!!
    C'est eux "les masters" qui chapeautent un projet énorme pour un groupe à taille européenne.

    J'ai jeter un œil à la table principale, celle du "produit en question" : 297 colonnes !!
    (Et ça c'est qu'un partie de l'iceberg)

    Ça va pas être jolie à voir dans quelques années.
    L'avenir appartient à ceux... dont les ouvriers se lèvent tôt. (Coluche)

  19. #19
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    Février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : Février 2010
    Messages : 3 611
    Points : 9 743
    Points
    9 743
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par mactwist69
    Ça fait pas de mal d'avoir une petite piqûre de rappel sur des principes qu'on ne devrait pas oublié.
    C'est sûr, mais il est aussi vrai qu'il est difficile d'avoir tous les principes à l'esprit quand il faut à la fois gérer le dév applicatif et le dév SQL... En plus en général dans les grandes structures, les DBA n'interviennent que rarement en amont car cela nécessite du budget. Ils sont plus souvent en aval à corriger les erreurs des dévs, mais une fois que c'est parti en prod c'est un peu tard pour corriger...

    Citation Envoyé par mactwist69
    Projets pilotés par des "développeurs-hyper-pointus-que tu-peux-pas-teste"...
    Il faut s'en méfier comme la peste. Ce sont ces mêmes qui au début du projet t'expliquent par A+Z que la phase de design (architecture) ne sert à rien pour gagner du temps. Et ce sont encore eux qui, au bout de quelques temps, vont constater que les performances s'effondrent et vont tout faire pour cacher leur erreur, à défaut de ne pas tout simplement passer à côté du diagnostic... Bref, sacrés Belges

    Citation Envoyé par mactwist69 Voir le message
    J'ai jeter un œil à la table principale, celle du "produit en question" : 297 colonnes !!
    (Et ça c'est qu'un partie de l'iceberg)

    Ça va pas être jolie à voir dans quelques années.
    Fracture de la rétine.
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  20. #20
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    Pour un projet de datawarehouse, c'est acceptable ? C'est une vraie question... Je n'ai jamais participé à ce type de projet et n'en connait pas les tenant et les aboutissants.

    N.B. : Je m'attends comment fortement à ce que la réponse soit non.
    Kropernic

Discussions similaires

  1. Base de données et méthodologie de développement.
    Par Pierre8r dans le forum JTheque
    Réponses: 1
    Dernier message: 10/08/2009, 18h43
  2. connexion base de donné
    Par saidi dans le forum MFC
    Réponses: 3
    Dernier message: 07/08/2002, 23h22
  3. [Concept] Stabilité d'une base de donnée
    Par lassmust dans le forum Décisions SGBD
    Réponses: 3
    Dernier message: 03/07/2002, 17h16
  4. Bases de données
    Par dev dans le forum C++Builder
    Réponses: 4
    Dernier message: 01/07/2002, 23h55
  5. associer une base de données(access) a un dbgrid
    Par ange1708 dans le forum MFC
    Réponses: 3
    Dernier message: 11/06/2002, 13h18

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