Discussion :

[grob1212]

Bonjour,

je suis débutant en base de données et je me pose une question :
dans mon application je vais avoir des milliers d'utilisateurs et des milliers de lignes de données par utilisateur que je vais stocker dans une base. Est-ce que créer une table par utilisateur présente un intérêt (en performance) par rapport à la création d'une table globale dans laquelle chaque ligne de données contient l'id de l'utilisateur ?
(les ensembles [utilisateur+ ses lignes de données] sont indépendants).

Merci beaucoup !

[fsmrel]

Bonjour,

Est-ce que créer une table par utilisateur présente un intérêt (en performance) par rapport à la création d'une table globale dans laquelle chaque ligne de données contient l'id de l'utilisateur ?

Si vous aviez 300 millions d'utilisateurs, créeriez-vous autant de tables ? Certes non. En plus si vous créiez une table pour chacun de vos milliers d'utilisateurs, comment feriez-vous par exemple pour rechercher tous ceux qui sont localisés dans telle ville ? Vous iriez explorer chaque table ?

Vous créerez plutôt une table unique appelée Utilisateur, qui contiendra une ligne par utilisateur et pour savoir quels sont ceux qui, par exemple, habitent Marseille, vous utilisez une requête du genre :

Select NomUtilisateur
From Utilisateur
Where Ville = 'Marseille'

La performance dépendra des index mis en place.

[grob1212]

Merci pour ce commentaire, mais je vais un peu préciser mon problème pour être sûr de bien comprendre votre réponse.

Prenons un exemple fantaisiste et sans intérêt :
imaginons un système qui permet d'enregistrer l'historique des pages visitées pour chaque utilisateur d'un site internet, avec une forte fréquentation.

je vois deux optiques :
- créer une table users dans laquelle on stocke les informations générales sur les utilisateurs et une table historique dans laquelle on stocke l'url de toutes les pages visitées pour tous les utilisateurs.

- créer une table user qui contient les mêmes informations et autant de tables d'historique qu'il y a d'utilisateurs, en sachant pertinemment que la recherche se limitera à un et un seul utilisateur particulier.

Dans le cas où j'ai des millions d'enregistrements, est-ce que le fait de séparer les historiques des utilisateurs dans des tables différentes amène un gain de performance ?

Merci.

[fsmrel]

créer une table users dans laquelle on stocke les informations générales sur les utilisateurs et une table historique dans laquelle on stocke l'url de toutes les pages visitées pour tous les utilisateurs.

Imaginons le système de tables :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
TABLE Utilisateur
( UtilisateurId   Integer       Not Null,
 Pseudo           Varchar(16)   Not Null,
 AdrCourriel      Varchar(48)   Not Null,
 ...
 PRIMARY KEY (UtilisateurId) ...) ;
 
TABLE HISTORIQUE
( UtilisateurId   Integer       Not Null,
  VisiteId        Integer       Not Null,
  DateVisite      Date          Not Null,
  UrlVisite       Varchar(255)  Not Null, 
 ...
 PRIMARY KEY (UtilisateurId, VisiteId)
 FOREIGN KEY (UtilisateurId) References Utilisateur ...) ;

Sur la table Utilisateur sera connecté au moins un index pour l’attribut UtilisateurId, voire un autre sur l’attribut Pseudo, etc., en fonction des besoins. En tout état de cause, l’accès à un utilisateur donné est très rapide. Par exemple, avec DB2 for z/OS, pour retrouver l’adresse de courriel de l’utilisateur 1024 :

Code :

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

1
2
3
SELECT  AdrCourriel
FROM    Utilisateur
WHERE   UtilisateurId = 1024 ;

Et en supposant que la table Utilisateur contienne cent mille utilisateurs, au cas où la donnée n’est pas déjà en mémoire, DB2 lira deux pages de l’index branché sur l’attribut UtilisateurId plus la page de données de la table elle-même, ce qui à quelques millisecondes la lecture est économique. Si la table contient 30 millions d’utilisateurs, il y aura 1 page index de plus à lire, autant dire peanut. Et puis vous pouvez réduire le nombre de niveau d’index grâce à la technique du partitionnement (si votre SGBD le permet).

Concernant la table Historique, les chiffres sont à peu près du même ordre de grandeur, sinon que la clé ayant une taille double de celle de la table Utilisateur, pour 30 millions de lignes il faudra compter 4 pages index à lire au lieu de 3, ce qui n’est toujours pas grand-chose.

créer une table user qui contient les mêmes informations et autant de tables d'historique qu'il y a d'utilisateurs, en sachant pertinemment que la recherche se limitera à un et un seul utilisateur particulier

Au vu de ce qui précède, le gain en performance sera imperceptible.
Sachant qu’un jour vous éprouverez le besoin de croiser les données, avec ce deuxième scénario vous serez coincé.
En plus, à chaque fois que vous aurez un nouvel utilisateur, vous devrez en passer par la création d’une nouvelle table historique et des index à brancher, la supprimer quand vous supprimez un utilisateur : beaucoup de travail en perspective, pour rien.

[grob1212]

Merci beaucoup pour ces explications, c'est très clair maintenant. Je ne connaissais pour ainsi dire pas les index, ca va me permettre de mieux penser mes bases de données.