Swisslinux.org

− Le carrefour GNU/Linux en Suisse −

 

Langue

 

Le Forum

Vous n'êtes pas identifié.

#1 10 Apr 2005 10:24:35

Xunlix
Affranchi(e)
 
Date d'inscription: 10 Apr 2005
Messages: 1

[MySQL] Quelle structure choisir ? (Non Résolu)

Petite question.

Je dois monter un site web qui permettra de faire des réservations de chambres d'hôtel par exemple. Je veux créer un compte d'utilisateur (pas de client, mais d'établissement hôtelier) pour chaque hôtel donc. Je me demande si du point de vue de la sécurité et de la stabilité du système, il n'est pas mieux de créer une base de donnée par établissement au lieu de créer une table pour chaque établissement dans une même base de données, sachant qu'il faut que le système gère plus de 8000 établissements, comptant chacun au moins 5 tables. Ce qui fait 40 000 tables à gérer et environ 80 000 000 d'enregistrement au total par année pour toutes ces tables.
Et quel est la capacité maximal de MySQL sachant que les serveur tourneront sur Linux, ou si quelqu'un a une meilleure idée qu'il m'en fasse part. :-)

Hors ligne

 

#2 10 Apr 2005 14:31:42

Swebian
Invité
 

Re: [MySQL] Quelle structure choisir ? (Non Résolu)

En passant tu as déjà fait tes modélisations ? La charge n'est sûrement pas un souci avec Linux.

 

#3 10 Apr 2005 16:45:31

BOFH
Admin
Lieu: Ecublens, VD
Date d'inscription: 03 Feb 2005
Messages: 862
Site web

Re: [MySQL] Quelle structure choisir ? (Non Résolu)

Hello,

   Ici, c'est le cahier des charges en matière de fonctionnalités qui est important pour la décision. Ton client ne sera pas content si par la suite il désire une fonctionnalité qui ne sera pas implémentable a cause d'une décision précédente motivée uniquement par la sécurité.

  Pour des fonctionnalités étendues, l'approche théorique est d'avoir une table par relation dans le modèle. La séparation entre les clients se fait sur la valeur d'un champ. Ceci permet de faire facilement des requêtes ou statistiques recouvrant plusieurs clients. La performance n'est pas forcément moins bonne qu'avec des tables séparées, si les index sont créés de manière pertinente.

  Si les différents clients ne doivent pas mutuellement avoir accès à leur données, il est préférable de créer des bases séparées, ou eventuellement (si le SGDB le permet, genre PostgreSQL), une seule base avec des schémas séparés.

  Utiliser une table par client dans la même base est une solution bâtarde qui n'offre ni la flexibilité de la première, ni la sécurité de la deuxième, et te force à utiliser du sql dynamique pour généraliser l'application (a cause de l'espace de noms unique), ce qui ne peut pas être bon du point de vue de la performance.

  En ce qui concerne les performances, cela dépend beaucoup de la complexité de tes requêtes. D'ailleurs, une conception soigneuse de ces requêtes sera plus importante pour la performance que le choix d'un SGDB. Sur des simples select, avec un index bien choisi, j'ai vu MySQL répondre en 2-3 secondes sur une table d'~ un million d'enregistrements.

  Si tes requêtes sont assez simples pour être bien gérées par MySQL, il sera certainement difficile de trouver une solution plus rapide. Mais la rapidité ne fait pas tout. Si tu as besoin de transactions sérialisables, de load-balancing a travers plusieurs serveurs, de fonctions SQL écrites dans un autre langage, ou de requêtes compliquées dont l'optimisation est non-triviale pour la machine, je recommanderait plutot PostgreSQL, qui offre ces fonctionnalités.

  Mes 2 centimes sur la question, comme on dit.

Hors ligne

 

Pied de page des forums

Powered by FluxBB