Discussion :

[whitespirit]

Bonjour,

Ma question peut paraitre bête et si je n'avais pas vu ce cas je ne me la serai pas poser : j'ai une grosse table contenant 40 champs et je me disais que la charger à chaque fois va peut-être me poser des problèmes de lenteur à un moment donné. Mais de toute façon lorsque je dois afficher les informations, tout doit apparaitre dans une même page (si c'est problématique d'ailleurs, je peux le faire dans 2 pages).

Alors, quelle est la solution qui serait la mieux adapté ? 40 champs dans une table, c'est une folie, il faut l'optimiser en découpant en plusieurs tables (j'ai vu ça dans une base de données d'un OpenSource réputé mais la bd date de 2003).

Sinon, j'ai déjà mis des indexes...

Merci de vos conseils

[Alain Defrance]

Bonjour,

Impossible de te répondre avec certtitude avant que tu nous expose ton domaine de gestion, mais il est généralement préférable, de séparer les informations en plusieurs tables.

[whitespirit]

Par exemple, mes deux tables les plus grandes (les seules d'ailleurs) sont celles représentant un bon de commande et un devis. J'ai plusieurs types d'informations :
- Les infos concernant les prix (ht, ttc, remise, etc.)
- Les infos concernant les dates (date de livraison proposé, donné, création, etc)
- Les infos concernant le contact (nom, prenom...)
- Les clés étrangères (donnant suite aux jointures : mode de reglement, udm, devise...)
- Les infos génériques à toutes les tables (archivés, visibles, date de dernière modif...)

Voilà, le tout fait au moins 40 champs facile.

[Alain Defrance]

Bonjour,

je verrais bien une table de contact par exemple.

En suite pour (sauf pour certaines optimisations), il est bien d'éviter de stocker des données calculables.

[whitespirit]

Bonjour,

Pas de table contact : il s'agit d'un contact fournisseur, cad la personne qui a répondu au devis.
Pas de données calculable : il s'agit uniquement (c'est ce qui est triste) de données élémentaires.

Merci

[Sivrît]

Pas de table contact : il s'agit d'un contact fournisseur, cad la personne qui a répondu au devis.

Il devrait s'agir par exemple d'une donnée qui revient pas mal, ce qui laisse penser que tout ça n'est pas très normalisé.

La question sera probablement de savoir s'il y a des requêtes qui passent outre les indexes. S'il y en a et qu'elles peuvent n'utiliser qu'une des 2 tables le gain pourrait être appréciable. Si c'est pour réaliser un accès indexé et de toute façon sortir toutes les données ça ne changera probablement pas grand chose. Je m'avance peut-être un peu, mais est-ce qu'un trafic important est attendu ? Parce que pour saturer une BDD en tirant 1 enregistrement (même avec 40 champs) via un indexe pour l'affichage d'une page il faudra y aller...

[whitespirit]

Non, il n'y aura pas de trafic sur ce site, une 10-15aines de personnes connectés en même temps, vraiment au grand max ! Sinon, j'aurai en moyenne 3-4 personnes travaillant quotidiennement sur l'application.

Du coup, je me casse la tête pour rien ?

PS: j'ai bien identifié les données élémentaires dans cette table. La couper en 2 tables serait uniquement pour des questions d'optimisation mais maintenant, est-ce que j'ai réellement besoin d'optimiser à ce niveau ? Je n'ai pas la réponse !

[MeDioN]

La couper en 2 tables serait uniquement pour des questions d'optimisation

Ca sert à rien.

[Alain Defrance]

Ça sert à rien.

Ce n'est pas que ça sert a rien, ça évite la redondance d'information (chose que le modèle MERISE s'efforce d'éradiquer).

Une jointure est l'une des opérations les plus lourdes que l'on peut demander a un SGBD, même si grâce aux index, elles deviennent raisonnablement utilisables.
Et comme l'on sait, on nous conseille de séparer au maximum les informations en plusieurs tables.
Les puristes conseilleraient même d'avoir une table par propriétée ...
Le nombre de jointure devient alors énorme et donc lourd pour le SGBD.
Il convient alors d'utiliser des vues pour regrouper les différentes entiées, et leurs donner ainsi un sens plus prononcé au sein du domaine de gestion.

Au final on a peu de redondance et peu de jointure puisque l'on utilise uniquement les vues pour acceder aux données, certains experts irons jusqu'a dire qu'il ne devrais pas être autrement, et que l'acces aux informations devrais se faire uniquement au travers de vues.