[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 :D

Bonjour,

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

Citation:

---

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 !


;)

Bonsoir Chtulus, Merci de ta réponse :D

Je vais lire cet article avec attention...

par contre :

Citation:

---

Pensez aux index !

---

Je ne comprends pas ce que tu veux dire :?

As-tu un lien ?

Merci encore et bonne soirée

Citation:

---

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 !

Citation:

---

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 !

Citation:

---

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 +

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 ;)

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 ;)

Citation:

---

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 ?

---

bonsoir, pour la troisieme, pour mieu modeliser ta base de donnée, je vous propose d'apprendre MERISE, tu peux trouver sur developpez-->tutoriel

bonne chance alors