Publicité

Affichage des résultats du sondage: Combien votre base de données contient-elle de tables avec plus de 20 colonnes ? (une seul choix pos

Votants
30. Vous ne pouvez pas participer à ce sondage.
  • Moins de 5%

    16 53,33%
  • Moins de 10%

    4 13,33%
  • Moins de 20%

    3 10,00%
  • PLUS de 20%

    7 23,33%
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 4 1234 DernièreDernière
Affichage des résultats 1 à 20 sur 74
  1. #1
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 407
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 407
    Points : 27 549
    Points
    27 549

    Par défaut Petites tables ou grandes tables. . . Quelles conséquences sur les performances ?

    Bonjour,

    La plupart des développeurs sont persuadés que mettre toutes les informations dans une même table rendra leur base de données plus rapide... Et l'on voit apparaître dans la base de nombreuses tables de plusieurs dizaines de colonnes. C'est une vue à court terme, car dés que la base de données commence à croitre ou que le nombre d'utilisateur augmente, les performances deviennent vite catastrophique... Cet article explique pourquoi...

    http://blog.developpez.com/sqlpro/p1...ances-petites/

    Vos commentaires sont les bienvenus !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  2. #2
    Modérateur

    Homme Profil pro Fabien
    Ingénieur d'études en décisionnel
    Inscrit en
    septembre 2008
    Messages
    6 835
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabien
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études en décisionnel
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2008
    Messages : 6 835
    Points : 13 511
    Points
    13 511

    Par défaut

    Bon article, j'y mettrai deux bémols dont on peut discuter.

    Les verrous
    Avec Oracle, un verrou exclusif ne bloque que la ligne en écriture, pas toute la table. On peut toujours lire la table, insérer de nouvelles données, mettre à jour des données sur d'autres lignes.
    Donc ce n'est pas pénalisant outre mesure.

    Le type de base de données
    Par type j'entends utilisation. Une base de données OLTP ou OLAP n'ont pas du tout les mêmes contraintes d'utilisation. La première fait beaucoup de petites opérations fortement transactionnées multi utilisateurs, la seconde est mono utilisateur, lecture seule en journée et mise à jour la nuit.
    Les pros de la dénormalisation en OLAP auront sûrement quelques arguments à avancer (mais je n'en fais pas partie).

    Edit : 21% sur ma base OLAP ! Je vais me faire disputer !

  3. #3
    Expert Confirmé Avatar de iberserk
    Homme Profil pro Bruno IGNACE
    Architecte de base de données
    Inscrit en
    novembre 2004
    Messages
    1 624
    Détails du profil
    Informations personnelles :
    Nom : Homme Bruno IGNACE
    Âge : 32
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2004
    Messages : 1 624
    Points : 2 667
    Points
    2 667

    Par défaut

    Edit : 21% sur ma base OLAP ! Je vais me faire disputer !

    Bon c'est du OLAP alors ca va
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

  4. #4
    Membre Expert

    Homme Profil pro François Durand
    Ingénieur Exploitation Mainframe
    Inscrit en
    octobre 2005
    Messages
    1 222
    Détails du profil
    Informations personnelles :
    Nom : Homme François Durand
    Âge : 55
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Exploitation Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 222
    Points : 2 097
    Points
    2 097

    Par défaut

    Je ne comprends pas cette phrase de l'article :

    Différences entre des petites tables et une grosse table pour les opérations de mises à jour (écriture) :

    • Dans une grosse table contenant un grand nombre de colonnes, chaque écriture (INSERT, UPDATE or DELETE) pose un verrou exclusif tant est si bien que personne d'autre ne peut l'utiliser.
    Mais pour l'auteur de l'article le verrou exclusif est posé sur quoi ?

  5. #5
    Membre du Club
    Inscrit en
    décembre 2008
    Messages
    35
    Détails du profil
    Informations forums :
    Inscription : décembre 2008
    Messages : 35
    Points : 60
    Points
    60

    Par défaut

    ca me semble vraiment un raccourci rapide

    ce que je retiens de l'article, c'est qu'il faut bien respecter la normalisation...

    Apres honnetement, ca me semble un raccourci rapide de dire si vous avez plein de tables avec plein de colonnes vous aurez des problemes de performances...

    Soyons serieux 5 minutes, par exemple il y a des milliers de systèmes SAP dans le monde avec des bases de données de plusieurs To , avec des dizaines de milliers de tables contenant parfois des dizaines de colonnes et ces systèmes fonctionnent très bien...

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 407
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 407
    Points : 27 549
    Points
    27 549

    Par défaut

    Vous avez raison, je perle de base de données relationnelles, pas décisionnelles.
    Sur le nombre de colonnes par table, même SAP reste dans les standards.
    En sus il faut aussi relativiser... 50 colonnes dont 40 de type booléen, ce n'est pas grand chose.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  7. #7
    Invité de passage
    Inscrit en
    juillet 2011
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : juillet 2011
    Messages : 1
    Points : 2
    Points
    2

    Par défaut Vive la théorie...

    Ca m'a l'air bien théorique et bien coloré "noir ou blanc"... Ou bien on est "normalisé" ou bien on met "tout dans une seule table"... Un peu exagéré comme commentaire, non?

    Si on parle Oracle, je ne vois pas comment joindre des tables de millions de lignes ne coûte "presque rien".
    exemple:
    CLIENT( id, nom, ... )
    PROFESSION( id, flag_liberale, description, ... )
    PROFESSIONS( client_id, flag_prof_principale, profession_id )
    ADRESSES( client_id, adresse_no, code_postal, rue, ... )
    Et maintenant je cherche les gens ayant une profession libérale et habitant dans "75...."
    Code :
    1
    2
    3
    4
    5
    6
    7
    SELECT DISTINCT c.nom AS prospect, ...
    FROM client c, profession p, professions cp, adresses a
    WHERE c.id = cp.client_id
    AND c.id = a.client_id
    AND a.code_postal LIKE '75%'
    AND cp.profession_id = p.id
    AND p.flag_liberale = 1
    Cet exemple est simple et un peu naif mais il va quand même "ramer"...
    Siebel par exemple a fait un peu de dénormalistation en entrant l'adresse principale dans la table "client". Ca devient
    Code :
    1
    2
    3
    4
    5
    6
    7
    SELECT c.nom AS prospect, ...
    FROM client c, profession p, professions cp
    WHERE c.id = cp.client_id
    AND c.code_postal LIKE '75%'
    AND p.flag_liberale = 1
    AND p.id = cp.profession_id
    AND cp.flag_prof_principale = 1
    (oui oui, pas tout à fait le même "result set", il faut sacrifier un peu sur l'autel de la performance)
    Et on peut mettre aussi un flag "prof_liberale" dans CLIENT pour arriver à
    Code :
    1
    2
    3
    4
    SELECT c.nom AS prospect, ...
    FROM client c
    WHERE c.code_postal LIKE '75%'
    AND c.flag_liberale = 1
    Quand on doit faire ce genre de recherche en temps réel pour des millions et des millions de clients, la théorie retourne dans les livres.
    J'ai des tables qui ont plus d'un milliard d'enregistrements
    J'ai des tables qui ont plus de 800 colonnes ((heureusement, pas les mêmes ;-))
    J'ai des utilisateurs qui ne se plaignent pas (enfin, pas toujours) de la performance.

  8. #8
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 813
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 813
    Points : 23 068
    Points
    23 068

    Par défaut

    Et maintenant je cherche les gens ayant une profession libérale et habitant dans "75...."
    Code :
    1
    2
    3
    4
    5
    6
    7
    SELECT DISTINCT c.nom AS prospect, ...
    FROM client c, profession p, professions cp, adresses a
    WHERE c.id = cp.client_id
    AND c.id = a.client_id
    AND a.code_postal LIKE '75%'
    AND cp.profession_id = p.id
    AND p.flag_liberale = 1
    La syntaxe normalisée pour les jointures utilise depuis 19 ans l'opérateur JOIN ; il serait temps de s'y mettre !
    Code :
    1
    2
    3
    4
    5
    6
    7
    SELECT DISTINCT c.nom AS prospect, ...
    FROM client c
    INNER JOIN professions cp ON c.id = cp.client_id
      INNER JOIN profession p cp.profession_id = p.id
    INNER JOIN adresses a ON c.id = a.client_id
    WHERE a.code_postal LIKE '75%'
      AND p.flag_liberale = 1
    Cet exemple est simple et un peu naif mais il va quand même "ramer"...
    Peut-être en partie à cause du LIKE '75%'

    Quand on doit faire ce genre de recherche en temps réel pour des millions et des millions de clients, la théorie retourne dans les livres.
    Ou bien on se repenche sur son modèle de données, surtout quand :
    J'ai des tables qui ont plus de 800 colonnes
    Quelle entité peut bien avoir 800 propriétés différentes, toutes non nulles ?
    J'ai des utilisateurs qui ne se plaignent pas (enfin, pas toujours) de la performance.
    Heureusement que c'est du Oracle, probablement sur un serveur correctement dimensionné !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  9. #9
    Membre Expert

    Homme Profil pro François Durand
    Ingénieur Exploitation Mainframe
    Inscrit en
    octobre 2005
    Messages
    1 222
    Détails du profil
    Informations personnelles :
    Nom : Homme François Durand
    Âge : 55
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Exploitation Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 222
    Points : 2 097
    Points
    2 097

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    La syntaxe normalisée pour les jointures utilise depuis 19 ans l'opérateur JOIN ; il serait temps de s'y mettre !
    Syntaxe normalisée ou pas, et malgré ce que certains martèlent ici, ça n'a aucune influence sur les performances ...

    Quelle entité peut bien avoir 800 propriétés différentes, toutes non nulles ?
    800 colonnes ça commence à faire beaucoup effectivement ... Mais entre 20 et 800 on doit pouvoir trouver un juste équilibre. Par ailleurs je trouve cette pseudo-limite des 20 colonnes totalement absurde.

  10. #10
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 407
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 407
    Points : 27 549
    Points
    27 549

    Par défaut

    Luc, donne moi plus de 20 attributs directement lié à :
    1) une personne
    2) une facture
    3) un produit
    ...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  11. #11
    Membre Expert
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 682
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : mars 2005
    Messages : 1 682
    Points : 2 329
    Points
    2 329

    Par défaut

    Des coordonnées dans un espace à 20 dimensions

  12. #12
    Expert Confirmé Sénior
    Homme Profil pro
    Inscrit en
    mai 2002
    Messages
    3 037
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 3 037
    Points : 4 613
    Points
    4 613

    Par défaut

    Citation Envoyé par nathalie.laudun Voir le message
    Quand on doit faire ce genre de recherche en temps réel pour des millions et des millions de clients, la théorie retourne dans les livres.
    J'ai des tables qui ont plus d'un milliard d'enregistrements
    J'ai des tables qui ont plus de 800 colonnes ((heureusement, pas les mêmes ;-))
    J'ai des utilisateurs qui ne se plaignent pas (enfin, pas toujours) de la performance.
    Et où est votre table code_postal + la table d'association entre votre "personne" et celle-ci ?

    Vous vous mettez des battons dans les roues tout seul si je ne m'abuse ?


    Là vous connaissez votre volumétrie, vos besoin fonctionnelles et vous ne vous adaptez pas ..

  13. #13
    Membre Expert Avatar de Yanika_bzh
    Homme Profil pro Yannick
    Responsable Applicatif et R&D
    Inscrit en
    février 2006
    Messages
    1 144
    Détails du profil
    Informations personnelles :
    Nom : Homme Yannick
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Responsable Applicatif et R&D
    Secteur : Finance

    Informations forums :
    Inscription : février 2006
    Messages : 1 144
    Points : 1 592
    Points
    1 592

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Luc, donne moi plus de 20 attributs directement lié à :
    1) une personne
    2) une facture
    3) un produit
    ...

    A +
    Par exemple une voiture :

    Année Production
    Poids
    Répartition AV/AR (kg)
    Longueur
    Largeur
    Hauteur
    Empattement
    Jantes
    Pneumatique
    Type (Nb Cylindres)
    Position
    Materiaux (Culasse/Bloc)
    Nombre de soupapes par cylindre
    Distribution
    Alimentation allumage
    Suralimentation
    Cylindrée (Cm3)
    Alésage x course (mm)
    Rapport Volumétrique
    Régime Maximum (tr/min)
    Puissance Maxi (ch à tr/min)
    Puissance au litre (ch)
    Couple maxi (mkg a tr/min)
    Couple au litre (mkg)
    Boite de vitesse
    Nombre de vitesse
    Transmission
    suspension Avant
    Suspension Arriere
    Direction
    Type de Freins
    Diametres des Freins (mm
    Etrier
    Piston

    non ?
    Dans la connaissance du monde, ceux qui ne savent rien en savent toujours autant que ceux qui n'en savent pas plus qu'eux. (Pierre Dac)

  14. #14
    Membre Expert Avatar de Yanika_bzh
    Homme Profil pro Yannick
    Responsable Applicatif et R&D
    Inscrit en
    février 2006
    Messages
    1 144
    Détails du profil
    Informations personnelles :
    Nom : Homme Yannick
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Responsable Applicatif et R&D
    Secteur : Finance

    Informations forums :
    Inscription : février 2006
    Messages : 1 144
    Points : 1 592
    Points
    1 592

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    La syntaxe normalisée pour les jointures utilise depuis 19 ans l'opérateur JOIN ; il serait temps de s'y mettre !
    Comme Luc, cette remarque perpétuelle a le don de m'agacer...
    En effet, la syntaxe normalisée pour les jointures est de deux types : EXPLICITE et IMPLICITE. Si effectivement SQL92 definit la jointure explicite, La BNF SQL92 ne bannit pas la jointure implicite.
    En effet vous trouverez dans la regle de la grammaire SQL (BNF Grammar for ISO/IEC 9075:1992 - Database Language SQL (SQL-92)) pour la clause FROM :

    FROM <from_clause>

    <from_clause> ::= FROM <table_reference>[{<comma><table_reference>}...]

    <comma> ::= ,

    En suivant donc cette grammaire, rien n'empeche d'ecrire

    FROM TableA, TableB

    Donc la norme d'une jointure n'est pas uniquement celle d'une jointure explicite.
    Vous pouvez (et j'en suis le premier) vous fixer une norme de developpement en n'utilisant que cette derniere, mais vous n'avez en aucun cas le droit de dire que c'est la norme SQL92 !!
    Dans la connaissance du monde, ceux qui ne savent rien en savent toujours autant que ceux qui n'en savent pas plus qu'eux. (Pierre Dac)

  15. #15
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 813
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 813
    Points : 23 068
    Points
    23 068

    Par défaut

    Peut-être, je ne connais pas la norme par coeur.
    Mais je ne compte plus le nombre de requêtes que j'ai débugguées dans nos forums rien qu'en récrivant les jointures avec la syntaxe explicite. C'est pas pour rien qu'on est passé du mélange des conditions de jointures et des conditions de restriction à leur séparation je pense ? Si cela a été fait, c'est que la syntaxe explicite est meilleure que la syntaxe implicite et c'est pour ça que je rappelle cette meilleure syntaxe et que j'encourage vivement tout le monde à l'utiliser et à bannir la vieille syntaxe qui présente tant de défauts.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  16. #16
    Expert Confirmé Avatar de iberserk
    Homme Profil pro Bruno IGNACE
    Architecte de base de données
    Inscrit en
    novembre 2004
    Messages
    1 624
    Détails du profil
    Informations personnelles :
    Nom : Homme Bruno IGNACE
    Âge : 32
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2004
    Messages : 1 624
    Points : 2 667
    Points
    2 667

    Par défaut

    Yanika_bzh concernant votre exemple (certes je chipote):
    toutes les données liées au moteur seraient dans une table à part puisque ces moteurs sont communs à plusieurs modèles...
    Les "embarquer" dans votre table principale entraîne une redondance de données...
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

  17. #17
    Membre Expert Avatar de Yanika_bzh
    Homme Profil pro Yannick
    Responsable Applicatif et R&D
    Inscrit en
    février 2006
    Messages
    1 144
    Détails du profil
    Informations personnelles :
    Nom : Homme Yannick
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Responsable Applicatif et R&D
    Secteur : Finance

    Informations forums :
    Inscription : février 2006
    Messages : 1 144
    Points : 1 592
    Points
    1 592

    Par défaut

    Citation Envoyé par iberserk Voir le message
    Yanika_bzh concernant votre exemple (certes je chipote)...
    Mais par exemple toutes les données liées au moteur serait dans une table a part puisque ces moteurs sont communs à plusieurs modèles...
    Les "embarquer" dans votre table principale entraîne une redondance de données...
    Cela depend la encore de votre expression de besoin.
    Imaginons que vous geriez des véhicules de courses, ceux ci possedent des caractéristiques modifiées par rapport a celles des constructeurs et des moteurs d'origine (ex, rabaissage de la cylindrée, rabottage des blocs, modification de la courses de pistons). Les modifications n'etant pas sérialisées, les caractéristiques non plus...

    Maintenant, vous avez raison, je veux gerer des voitures standards de série, elles peuvent posseder le meme modele de moteur, donc, hop normalisation, et je me retrouve avec une entitée moteur... Maintenant que vais je pouvoir mettre dans cette nouvelle table ?? Essayons pour voir :

    Identifiant : Necessaire bien sur
    Description
    Encombrement
    Energie
    Aspiration
    Nombre de cylindres
    Position des cylindres
    Alesage
    Cylindrée
    Rapport volumétrique
    Ordre d'allumage
    Sens de rotation
    Poids du moteur Equipé
    Couple Maxi
    Regime couple Maxi
    Regime Maxi a vide
    Regime mini ralenti
    Capacité d'eau
    Pression de pressurisation maximum
    Valeur de reglage thermostat
    ...
    ...
    Dans la connaissance du monde, ceux qui ne savent rien en savent toujours autant que ceux qui n'en savent pas plus qu'eux. (Pierre Dac)

  18. #18
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 407
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 407
    Points : 27 549
    Points
    27 549

    Par défaut

    De la même manière, le couple va dépendre de la boite de vitesse/cylindrée. Donc, sortez les attributs de couple dans une table de jointure moteur/BV.

    Vous commencez donc à, comprendre l'art de la modélisation !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  19. #19
    Membre Expert Avatar de Yanika_bzh
    Homme Profil pro Yannick
    Responsable Applicatif et R&D
    Inscrit en
    février 2006
    Messages
    1 144
    Détails du profil
    Informations personnelles :
    Nom : Homme Yannick
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Responsable Applicatif et R&D
    Secteur : Finance

    Informations forums :
    Inscription : février 2006
    Messages : 1 144
    Points : 1 592
    Points
    1 592

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    De la même manière, le couple va dépendre de la boite de vitesse/cylindrée. Donc, sortez les attributs de couple dans une table de jointure moteur/BV.

    Vous commencez donc à, comprendre l'art de la modélisation !

    A +
    Vous devez confondre couple MAXI et couple TRANSMIS ...
    Votre boite de vitesse ne modifiera pas le couple MAXI, mais le couple TRANSMIS.
    Dans la connaissance du monde, ceux qui ne savent rien en savent toujours autant que ceux qui n'en savent pas plus qu'eux. (Pierre Dac)

  20. #20
    Expert Confirmé Avatar de iberserk
    Homme Profil pro Bruno IGNACE
    Architecte de base de données
    Inscrit en
    novembre 2004
    Messages
    1 624
    Détails du profil
    Informations personnelles :
    Nom : Homme Bruno IGNACE
    Âge : 32
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2004
    Messages : 1 624
    Points : 2 667
    Points
    2 667

    Par défaut

    Vous devez confondre couple MAXI et couple TRANSMIS ...
    Votre boite de vitesse ne modifiera pas le couple MAXI, mais le couple TRANSMIS.

    J'allais le dire....

    SQL PRO: le couple affiché sur la fiche technique est le couple développé par le moteur... il ne dépend donc pas de la boite de vitesse.

    Mais nous chipotons...
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •