Discussion :

[Snooky68]

Bonjour à tous,

Je suis en train de développez une application ou chaque enregistrement n'appartient qu'a un seul et unique utilisateurs!

Pour un gain de performance lors des requêtes il serait donc mieux de créer une table pour chaque utilisateurs, (voir même une base de donnée par utilisateur). Plutôt que de créer un champs id_user et de faire des requêtes complexe sur des milliers d'enregistrement en triant suivant le user!

Cette méthode est-elle correcte? Et est-il possible de la mettre en œuvre dans django?

P.S: Cette question peut être mise dans SGBD je suppose, mais elle concerne spécifiquement django... alors je sais pas trop si elle est bien placé!

[andtwoturtles]

est-ce que tu es sûr que tu ne peux pas travailler avec les mêmes tables ?
parce que bon à partir du moment où tu as pas mal d'utilisateurs (disons quelques milliers) ta (tes) base de donnée doit commencer à le sentir passer. Peut être un gain de performance mais sans doute aussi une perte de place.

Normalement il y a moyen de se débrouiller avec les même table pour tous, même dans les grosses applications. Pour exemple, le Crédit Suisse à +/- 50.000 base de données (30Tb) et je pense pas que c'est une par client

Sinon pour les tables c'est faisable via une requête sql normale (create table...)
et pour créer une base de donnée je sais pas mais pour s'y connecté par exemple avec mysql c'est :

Code :

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

1
2
3
4
5
6
7
8
9
def connect(request,usr,pass):
    db = MySQLdb.connect(user=usr, db=usr+'.db', passwd=pass, host='localhost')
    cursor = db.cursor()
    cursor.execute('create table machin')
    ....
 
def logout(request,db):
    db.close()
    ....

normalement la façon "propre" est de passer par le settings.py mais comme ici tu dois pouvoir changer...

cf djangobook

[sjrd]

Moi franchement, il me semble que tu vas au contraire y perdre en performances. Je garderais la version simple avec une seule table et un champ 'user_id', implémenté par une ForeignKey django.

[wiztricks]

Bonsoir,

Plutôt que de créer un champs id_user et de faire des requêtes complexe sur des milliers d'enregistrement en triant suivant le user!

Tel que vous racontez votre besoin, il semble que la table pourrait n'avoir que 2 colonnes: l'ident de l'utilisateur et du "texte"...
Il faudrait que vous nous parliez des autres attributs de la ou des tables et du type de requêtes que vous envisagez faire.

Pour autant qu'il soit plus approprié d'utiliser des tables plutôt que des répertoires d'un file system... n'oubliez pas que le SGDB "en dessous" de Django, a sans doute des fonctionnalités pour traiter de grosses tables avec des temps de réponses acceptables.

Pour les très grosses, vous pouvez partitionner les tables en la découpant en n petites tables. Effectuer ce partitionnement "dans" une base de données, répartir les "petites" tables sur des serveurs différents.
Note: Sans recourir à de telles techniques, vous pouvez par utilisateur préciser sur quels serveurs sont ses données.

Si vous avez la chance de ne pas avoir a faire trop de requêtes pénalisées par le schéma, le principal soucis ne devrait être que la vitesse des disques - ou plutôt des possibilités de répartition de la charge d'IO.

- W

[Snooky68]

Bon ok... je croit que j'ai compris! Je vais en resté au système d'id.

Si un problème survient je pense que je suivrait ton conseil wiztricks. Partitionner la base de donnée!

Merci à tous!

[wiztricks]

Bon ok... je croit que j'ai compris! Je vais en resté au système d'id.

Si un problème survient je pense que je suivrait ton conseil wiztricks. Partitionner la base de donnée!

Merci à tous!

Ceci dit, avant que le problème n'arrive, pourquoi ne pas faire un échantillon des requêtes que ca va faire.
Un petit test de charge devrait pouvoir vous donner une idée des temps de réponses et à défaut de vous rassurer vous donner quelques indications sur le nombre d'utilisateurs "supportables".
- W