Discussion :

[oumay]

bonjour tous le monde,
ma question est comme suit : j'ai une table nommée Creance qui contient 10000 enregistrements. la taille de cette Table augmente de 10 enregistrement pour chaque insertion. j'ai 20 région qui vont se connecter pour consulter cette table. Donc, pour chaque région, au lieu de parcourir toute la table pour chercher une ligne j'ai besoin de cerner les lignes qui appartiennent à la région en question.

ma question est comment le faire pour optimiser la recherche et sans saturer la BD ??
merci d'avance pour l'aide.

[Engiwip]

pour la comprehension de tes donnnées la reponse est dans ton titre
et pour la perf tu places un index sur le champ le plus recherché.

[oumay]

merci pour la réponse,

donc il faut créer des vues, une vue pour chaque région ???

pour l'index comment le faire ??? juste déclarer un champs comme un index ou bien ???

[Michel.Priori]

Bonsoir,

Existe-t'il une relation entre les 10 lignes à chaque "insertion" et les 20 régions ?
Si oui, laquelle ?
Si non, pourquoi en avoir parlé ?

10 000 lignes à raison de 10 lignes par "insertion", on a 1 000 insertions.
Ok.
Ça c'est rempli en combien de temps ?
Quelle est la volumétrie "utile" ?
Avez vous des campagnes de purges ?

En imaginant que les régions ont grosso modo le même nombre de lignes, 1/20 de 10 000 ça représente 500 lignes.
Si le volume est maitrisé, alors un index est probablement la meilleure réponse.
Encore faut-il le(s) placer sur le(s) colonnes judicieusement.
Si le volume n'est pas maitrisé et que les requêtes utilisent à 90% le même critère alors le partitionnement sur les bonnes colonnes sera aussi un axe d'analyse (je n'ai jamais dit qu'il s'aggissait ici de la colonne région)

Les vues vous permettront de simuler un stockage par région pour chaque table qui dispose de la colonne région ; mais pas pour les autres...
On peut mettre à jour une table par le truchement d'une vue.
Or du fait que MySQL n'intègre pas la contrainte CHECK on peut, si elle est présentée, mettre à jour la colonne région et lui affecter NULL, ainsi la ligne "disparait" de toutes les vues.
Bref le choix de MySQL ne rend pas aisée la logique par vue et encore moins la création d'une "virtual private database" à la Oracle.

Si le besoin est fort je vous conseille de créer 20 schémas (1 par région) + 1 (commun) et donc de séparer les données.
La gestion des droits par schéma est simple et efficace.

[escartefigue]

J'abonde dans le sens de ce qu'à proposé Michel.Priori

J'ajoute que avant de créer un index sur le critère région, il faudra vérifier qu'il n'y a pas une ou deux régions "vedette" qui à elles seules représentent une grosse partie des lignes de la table, auquel cas l'index ne sera pas filtrant et donc inutile en terme de recherche (même s'il peut avoir un intérêt éventuel en tant qu'index couvrant)

Le partitionnement sur le critère région (si c'est le critère retenu pour le partitionnement) peut être intéressant aussi pour les concurrences d'accès (chaque partition vivra sa propre vie) ou si les contraintes d'exploitation de certaines régions sont différentes (ex : région dom-tom dont les heures de TP sont différentes de la métropole). En effet, vous pourrez passer des utilitaires (réorg, sauvegardes...) sur les régions hors horaires de bureau alors que les autres seront dédiées à la gestion.

[manzeki]

Le rôle des vues n'est pas d'améliorer le temps d'exécution de vos requêtes.
Les performances dépendent naturellement de la modélisation et des requêtes qui sont formulées.
Dans votre table creance, vous devriez avoir une colonne qui identifie chaque ligne par region (region_id)
A priori, c'est sur cette colonne qu'il faut poser un index.

Si votre colonne s'appelle region_id, faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE INDEX creance_region ON creance(region_id);

[escartefigue]

Le rôle des vues n'est pas d'améliorer le temps d'exécution de vos requêtes.

à l'exception des vues matérialisées, mais sauf erreur de ma part, MySQL ne les propose pas

[manzeki]

à l'exception des vues matérialisées, mais sauf erreur de ma part, MySQL ne les propose pas

Non, MySQL n'implémente pas encore de vues matérialisées.