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

Langage SQL Discussion :

[mysql] questions sur la conception


Sujet :

Langage SQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2006
    Messages
    530
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2006
    Messages : 530
    Par défaut [mysql] questions sur la conception
    Bonjour à tous,

    Je voudrais poser quelques questions afin d'en savoir plus sur la meilleure façon de concevoir une base de données mysql.

    1) Lorsqu'on lui demande de rechercher les champs contenant quelque chose, une requête SELECT est-elle plus rapide si ce champ peut-être NULL ou si ce champ ne peut pas être NULL mais ne contient rien ?

    2) une table est-elle plus légère lorsqu'elle contient des champs NULL ou lorsqu'elle contient des champs vides.

    3) est-il préférable d'avoir une table contenant des milliers de lignes ou plusieurs tables contenant des centaines de lignes ?
    par exemple est-il préférable de stocker des nouveaux clients dans des tables créées automatiquement par mois, ou par année ?
    Dans la mesure ou l'on recherche régulièrement les données de ces clients bien sûr ?

    Voilà une première série de question... qui en amènera certainement d'autres.

    Bonne journée à tous

  2. #2
    Modérateur
    Avatar de Chtulus
    Homme Profil pro
    Ingénieur
    Inscrit en
    Avril 2008
    Messages
    3 094
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur
    Secteur : Santé

    Informations forums :
    Inscription : Avril 2008
    Messages : 3 094
    Par défaut
    Bonjour,

    En ce qui concerne les NULL lisez l'article de SQLpro à ce sujet...

    3) est-il préférable d'avoir une table contenant des milliers de lignes ou plusieurs tables contenant des centaines de lignes ?
    par exemple est-il préférable de stocker des nouveaux clients dans des tables créées automatiquement par mois, ou par année ?
    Dans la mesure ou l'on recherche régulièrement les données de ces clients bien sûr ?
    Ce n'est pas une question d'être préférable, mais de conception...
    Pensez aux index !


    « Je ne cherche pas à connaître les réponses, je cherche à comprendre les questions. »
    - Confucius -

    Les meilleurs cours, tutoriels et Docs sur les SGBD et le SQL
    Tous les cours Office
    Solutions d'Entreprise



  3. #3
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2006
    Messages
    530
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2006
    Messages : 530
    Par défaut
    Bonsoir Chtulus, Merci de ta réponse

    Je vais lire cet article avec attention...

    par contre :

    Pensez aux index !
    Je ne comprends pas ce que tu veux dire

    As-tu un lien ?

    Merci encore et bonne soirée

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 998
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 998
    Billets dans le blog
    6
    Par défaut
    1) Lorsqu'on lui demande de rechercher les champs contenant quelque chose, une requête SELECT est-elle plus rapide si ce champ peut-être NULL ou si ce champ ne peut pas être NULL mais ne contient rien ?
    tout d'abord sachez que dans un SGBDR il n'y a pas de champs. Mais des colonnes et ce n'est pas du tout le même chose. La confusion terminologique vous induit déjà dans l'erreur. Lisez ce que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/sqlaz/erreurs/#L2
    Ensuite cette réponse ne dépend que peu des valeurs, mais essentiellement de l'indexation. A faible volume l'effet de l'indexation est peu visible. A fort volume il est énorme !

    2) une table est-elle plus légère lorsqu'elle contient des champs NULL ou lorsqu'elle contient des champs vides.
    La notion de légèreté n'existe pas. Peut être voulez vous parler de volumétrie, donc de stockage. Les deux choses n'étant pas du tout équivalente en parler de cette manière est stupide. Que diriez vous si on disait que votre garage doit toujours contenir une voiture, même transparente ? Ou iriez vous parquer le vôtre ???
    Le marqueur NULL a été inventé pour pallier les problèmes insolubles des systèmes à fichiers. Vouloir s'interdire les NULL est aussi stupide que d'obliger tout le monde à avoir une voiture, même invisible !

    3) est-il préférable d'avoir une table contenant des milliers de lignes ou plusieurs tables contenant des centaines de lignes ?
    par exemple est-il préférable de stocker des nouveaux clients dans des tables créées automatiquement par mois, ou par année ?
    Dans la mesure ou l'on recherche régulièrement les données de ces clients bien sûr ?
    Vous raisonnez en terme de fichiers, pas en terme de tables dans une base de données. tant que vous n 'abandonnerez pas votre mode de pensée "fichier" donc non ensembliste vous aurez tout faux !
    Bien évidemment faire 10 tables au lieu d'une seule est d'une grande bêtise. Encore une fois ce n'est pas le nombre des lignes dans la table qui pose un problème. C'est la modélisation de la base dans le respect des règles du modèle relationnel (et notamment le respect absolu des formes normales) , et l'indexation des données qui vous donnera toute la puissance nécessaire !

    En conclusion, commencez par apprendre ce qu'est une base de données relationnelle et tout ira mieux. Pour ce faire, mon site web, comme mes livres peuvent vous y aider !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  5. #5
    Membre Expert Avatar de pacmann
    Homme Profil pro
    Consulté Oracle
    Inscrit en
    Juin 2004
    Messages
    1 626
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Consulté Oracle
    Secteur : Distribution

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 626
    Par défaut
    Salut !

    Concernant ta troisième question, je voudrais tempérer un peu le propos de SQL Pro.

    En gros, si tu as toutes les factures de tous tes clients dans une et une seule table, le fait de poser le bon index sur (par exemple) l'identifiant du client porté par chaque facture, te permets d'accéder très vite au facture d'un client donné.
    => L'exemple n'est pas exact du tout, mais c'est vaguement comme "un livre par chapitre", ou avoir un gros livre, avec un index qui te permet de retrouver le chapitre qui t'intéresse...

    Cela dit, lorsque ta volumétrie augmente beaucoup (genre que ça commence à se compter en dixaine de millions), le fait d'avoir des données "mélangées" d'un point de vue physique peut ralentir sensiblement tes accès par indexes.

    Mais ça, c'est le problème de ton DBA ! Qui peut :
    - réorganiser les données
    - partitionner tables / indexes :
    http://krierjon.developpez.com/mysql...onnement/#L1.1
    - ... (je suis pas DBA, donc je peux pas te dire grand chose de plus )

    Voilà voilà, comme dirait le messieurs juste au dessus (avec les insultes en moins), construits-toi un joli modèle dans les règles de l'art, et laisse le reste de côté pour le moment

  6. #6
    Expert confirmé
    Profil pro
    Inscrit en
    Août 2008
    Messages
    2 953
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 2 953
    Par défaut
    Salut,

    Concernant l'utilisation ou non du NULL, je te laisse te faire ta propre opinion.

    En tout cas concernant les effets de bords du NULL je te conseille :
    Variations sur NULL, ou SUM(X+Y) <> SUM(X) + SUM(Y) ?
    Et ne pas oublier IN/NOT IN.

    Ca évite de se prendre inutilement la tête

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [XL-2013] Débutant avec des questions sur la conception d'un classeur et mysql
    Par maccoa dans le forum Conception
    Réponses: 3
    Dernier message: 13/11/2014, 06h53
  2. [MySQL] Pour un projet php/mysql : questions sur le langage et l'environnement
    Par 3wicha dans le forum PHP & Base de données
    Réponses: 1
    Dernier message: 18/07/2007, 18h21
  3. question sur le concepte de GTA
    Par Asmod_D dans le forum Développement 2D, 3D et Jeux
    Réponses: 6
    Dernier message: 27/02/2007, 12h34
  4. [MySQL] Question sur les GROUP BY
    Par Coladin dans le forum Langage SQL
    Réponses: 5
    Dernier message: 21/04/2006, 14h25
  5. [MYSQL] Question sur jointure
    Par LE NEINDRE dans le forum Requêtes
    Réponses: 4
    Dernier message: 17/10/2005, 11h46

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