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 :

conception sgbdr - performances et tables multiples (débutant)


Sujet :

Schéma

  1. #1
    Nouveau Candidat au Club
    Profil pro
    Inscrit en
    Août 2008
    Messages
    2
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Août 2008
    Messages : 2
    Points : 1
    Points
    1
    Par défaut conception sgbdr - performances et tables multiples (débutant)
    Bonjour,

    Je travaille actuellement à la conception d'un sgbdr à usage professionnel (un grand merci à MM. Brouard et Greissinger pour la qualité de leur travail...)

    Je souhaite utiliser PostGreSQL.

    Ma question est un peu simpliste :

    Que nous apporte l'utilisation d'une table (par exemple T_NUMEROTEL) liée à une plus importante (T_PERSONNE), par rapport à la définition du numéro de téléphone comme attribut de la table T_PERSONNE ?

    Même question avec T_TITRE ('M.', 'Mme', 'Melle') ?

    Quelle est la différence en termes de performances ?
    moins de calculs si attribut ?

    Avec un grand merci pour votre aide

  2. #2
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 058
    Points
    32 058
    Par défaut
    ça apporte de la flexibilité.

    Spécialement les numéros de téléphones : Avec des liens bien pensés, on peut attribuer plusieurs numéros de téléphone à une seule personne(domicile, bureau, portable.....).

    niveau performance, je ne sais pas. Mais fonctionellement, c'est plus souple.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  3. #3
    Nouveau Candidat au Club
    Profil pro
    Inscrit en
    Août 2008
    Messages
    2
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Août 2008
    Messages : 2
    Points : 1
    Points
    1
    Par défaut re :
    Merci bien..


Discussions similaires

  1. [Visual Studio][Débutant] DataGridView et tables multiples
    Par Anawae dans le forum Visual Studio
    Réponses: 0
    Dernier message: 10/06/2013, 11h01
  2. Conception et performances de lourdes tables
    Par Bisûnûrs dans le forum MySQL
    Réponses: 15
    Dernier message: 01/08/2008, 10h25
  3. Performances : ANALYSE TABLE, quelle fréquence ?
    Par Mr N. dans le forum SQL Procédural
    Réponses: 4
    Dernier message: 26/10/2005, 17h02
  4. tables multiples au lieu de table unique
    Par rafawel dans le forum Décisions SGBD
    Réponses: 1
    Dernier message: 13/07/2005, 11h41
  5. [Conception][performance] mysql table de 10000 enregistrements / hashmap
    Par debdev dans le forum Collection et Stream
    Réponses: 5
    Dernier message: 09/07/2005, 11h29

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