Discussion :

[MICHEL_R]

Bonjour,

Je suis en cours de réflexion sur le modèle physique de ma base de données.
Je dois positionner une table X qui relie 2 tables qui vont être volumineuses (Quelques millions d’enregistrements). Cette table X va contenir le produit cartésien (par dossier) des 2 autres. J’ai calculé en gros (selon les clients déjà existants) que cette table grossira d’une dizaine de millions d’enregistrements par an. Il faut savoir également que cette table contiendra peu de colonnes (10 max) et toutes seront indexées. Le SGBD est MySQL
Ma question est la suivante : sachant que beaucoup de recherches vont prendre place dans cette table, que faut-il penser d’une table qui contiendra 50 millions d’enregistrements dans 5 ans. Comment les performances seront affectées par un nombre de lignes si important ? En d’autres mots une telle volumétrie est-elle vouée à un ralentissement certain au fil du temps. Merci pour vos retours


Michel

[escartefigue]

Je dois positionner une table X qui relie 2 tables qui vont être volumineuses (Quelques millions d’enregistrements). Cette table X va contenir le produit cartésien (par dossier) des 2 autres.

Si c'est le produit cartésien vous reconstruirez le contenu à chaque fois que vous voudrez utiliser la table ?
Quel intérêt, à quoi vous servira vraiment cette table ?

Il faut savoir également que cette table contiendra peu de colonnes (10 max) et toutes seront indexées.

OK mais Est-ce que les valeurs seront discriminantes ? un index en tant que moyen de recherche n'étant efficient que si les valeurs sont discriminantes, il faut s'en assurer.

Ma question est la suivante : sachant que beaucoup de recherches vont prendre place dans cette table, que faut-il penser d’une table qui contiendra 50 millions d’enregistrements dans 5 ans. Comment les performances seront affectées par un nombre de lignes si important ? En d’autres mots une telle volumétrie est-elle vouée à un ralentissement certain au fil du temps. Merci pour vos retours

Tout dépend du type de requêtes que vous ferez sur cette table, si vous avez un prédicat sargable très filtrant, les temps de réponse peuvent être infimes

Pouvez vous communiquer la description de la table (DDL create table)

[MICHEL_R]

Merci pour le retour

Si c'est le produit cartésien vous reconstruirez le contenu à chaque fois que vous voudrez utiliser la table ?
Quel intérêt, à quoi vous servira vraiment cette table ?

Voici plus d'infos : l'appli gère les appels d'offres : On a donc une table dossiers (marchés) liée aux participants d'un côté et aux produits de l'autre coté. La table dont il est question ici est la table de la participation car un participant peut (ou pas) sélectionner un produit donné. Cette table donc est le lien entre Participants et produits. Un marché qui a 100 participants et 50 produits aura donc (50*100) possibilités. Cette table contiendra un Id unique, les clés étrangères de participants et produits, 2 dates, le résultat (Gagné ou perdu) et la quantité.

OK mais Est-ce que les valeurs seront discriminantes ? un index en tant que moyen de recherche n'étant efficient que si les valeurs sont discriminantes, il faut s'en assurer.

Oui ça c'est bon

Tout dépend du type de requêtes que vous ferez sur cette table, si vous avez un prédicat sargable très filtrant, les temps de réponse peuvent être infimes

Egalement OK

Pouvez vous communiquer la description de la table (DDL create table)

Je n'ai pas la DDL, la table n'est pas encore créée

Au niveau de la conception il y a d'autres manière de faire comme par exemple interpréter l'absence de résultat comme un résultat "gagné", ce qui ferait beaucoup moins de lignes mais ce n'est pas très propre d'un point de vue merise. Le faire propre engendre des gros volumes comme discuté précédemment. Qu'en pensez-vous ? Suis-je assez clair au niveau des explications ?

Michel

[escartefigue]

Au niveau de la conception il y a d'autres manière de faire comme par exemple interpréter l'absence de résultat comme un résultat "gagné", ce qui ferait beaucoup moins de lignes mais ce n'est pas très propre d'un point de vue merise. Le faire propre engendre des gros volumes comme discuté précédemment. Qu'en pensez-vous ? Suis-je assez clair au niveau des explications ?

C'est le principe même d'une base relationnelle, que de constituer des ensembles à partir des éléments en relation, le "faire propre" ne consiste donc pas à collectionner toutes les combinaisons potentielles (résultat d'un cross-join) mais bien uniquement les combinaisons réelles. L'absence d'une relation entre un produit et un participant, constitue une identification "propre" pour reprendre vos termes, et tout a fait dans la norme de modélisation Merise

[pier.antoine]

Bonjour

Si je comprends bien la dernière intervention d'Escartefigues, et en reprenant l'information de MICHEL_R

Un marché qui a 100 participants et 50 produits aura donc (50*100) possibilités.

un participant peut se positionner sur tout ou partie des 50 produits, et la table X contiendra uniquement les lignes des produits pour lesquels ce participant s'est positionné.Par exemple 3 lignes, avec les produits 5,17 26.

Est-ce au niveau de l'interface qu'il faut donner la possibilité de se positionner parmi les 50 produits ?

Pierre

[escartefigue]

Je ne sais pas de quelle interface il est question, mais avec un modèle de données comme suit (c'est un exemple bien sur) :



Vous pouvez identifier tous les participants ayant ou non sélectionné des produits, tous les produits ayant ou non été sélectionnés etc...
Bref toutes les extractions habituelles sur une base relationnelle

quelques exemples de requêtes classiques avec le modèle en exemple :

-- Liste des participants et de leurs produits
-- les participants n'ayant pas de produits sont listés quand même

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
select pa_id     as id_participant
     , pa_nompat as nom_patronymique
     , pa_prenom as prenom 
     , pr_code   as code_produit
     , se_date   as date_souscription
     , se_qte    as quantite
from   participant as PA
left outer join selectionner as SE
  on SE.PA_id = PA.PA_id
inner join produit as PR
  on PR.PR_id = SE.PR_id

-- liste des participants n'ayant souscrit aucun produit

Code SQL :

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

1
2
3
4
5
6
7
8
select pa_id     as id_participant
     , pa_nompat as nom_patronymique
     , pa_prenom as prenom 
from   participant as PA
where not exists
     (select null
      from selectionner as SE
      where SE.PA_id = PA.PA_id)

-- liste des produits non sélectionnés (aucun participant n'a souscrit)

Code SQL :

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

1
2
3
4
5
6
7
8
select pr_id
     , pr_code
     , pr_description
from produit as PR
where not exists
     (select null
      from selectionner as SE
      where SE.PR_id = PR.PR_id)

Dans l'exemple ci-dessus, vous n'avez pas la possibilité d'avoir plusieurs occurrences de sélection pour un même participant et un même produit
Sans doute faut il modéliser une entité-type date (avec un attribut pouvant être un timestamp) participant à la relation "selectionner" pour permettre ces occurrences multiples
ou tout simplement, modifier le MCD pour que la date contribue à la clef de la table "selectionner"

[pier.antoine]

Bonjour
Escartefigue,quand je parlais d'interface, je pensais applicatif.

Je pense que c'est au niveau de l'applicatif (le site?) que l'on pourra donner la possibilité aux participants de choisir parmi la totalité des produits.

Merci pour les MCD/MLD et les exemple de requêtes.

Pierre

[escartefigue]

Escartefigue,quand je parlais d'interface, je pensais applicatif.
Je pense que c'est au niveau de l'applicatif (le site?) que l'on pourra donner la possibilité aux participants de choisir parmi la totalité des produits.

Oui

Merci pour les MCD/MLD et les exemple de requêtes.

De rien, le but est surtout de montrer qu'il est rare d'avoir besoin de matérialiser le produit cartésien des tables issues des entités-type "participant" et "produit" et qu'au contraire, le plus souvent ce sont bien les éléments en relation, matérialisés par la table "selectionner", qui répondent aux besoins d'analyse et de gestion.

[MICHEL_R]

Bonjour a tous,
Merci pour le suivi.

J'ai pris un peu de retard :

Si je comprends bien la dernière intervention d'Escartefigues, et en reprenant l'information de MICHEL_R
Un marché qui a 100 participants et 50 produits aura donc (50*100) possibilités.
un participant peut se positionner sur tout ou partie des 50 produits, et la table X contiendra uniquement les lignes des produits pour lesquels ce participant s'est positionné.Par exemple 3 lignes, avec les produits 5,17 26.
Est-ce au niveau de l'interface qu'il faut donner la possibilité de se positionner parmi les 50 produits ?
Pierre

Que ce soit au niveau de l'interface ou de l'intégrité de la table en question on peut avoir 0 lignes ou bien (50*100). Maintenant l'essence même de ma question c'est ce qui suit (et c'est ce qui est un peu compliqué à faire comprendre) : supposons qu' on a 2 clients qui prennent chacun 1 produit, on a donc 2 lignes mais comment interpréter l'absence de lignes car la particularité de cette table est de répartir les quantités, de ce fait une absence de lignes n'indique pas que les qtés n'ont pas été réparties mais que tous les participants ont tous les produits. D'où mon idée première de remplir systématiquement cette table avec les (50*100) lignes de manière à m'assurer qu'un résultat existe vraiment. Mais je retourne à ma question première sur la volumétrie d'un table qui va grossir rapidement vers quelques dizaines de millions d'enregistrements et certainement les lenteurs qui vont avec.
Faites-moi savoir si c'est clair
Michel

[MICHEL_R]

Escartefigue,

Merci d'avoir pris la peine d'avoir fait le schéma relationnel et les requêtes.

Dans l'exemple ci-dessus, vous n'avez pas la possibilité d'avoir plusieurs occurrences de sélection pour un même participant et un même produit

c'est exactement ça.

Ensuite comme je l'explique dans mon post précédent, la problématique se situe plutôt au niveau de l'interprétation de l'absence de données

Michel