Re: [TECH] Limitation mysql

[Bernard Choppy <bernard AT choppy.fr>]

Bonjour à tous,

Je suis un peu étonné de cet échange.

A la base, se demander si on fait 40 000 tables devrait en soi - AMHA - 
mener à une remise en cause de la structure, je pense.

Je ne connais pas de moteur qui travaille bien dans ce genre de 
situations (si : un mainframe qui gère de l'ISAM en COBOL, sans doute ;-)).

En effet, chaque table et chaque colonne dans un SGBD/R correspondent à 
des enregistrements de définition dans les tables système (genre 
all_tables, all_columns, etc.) avec la gestion des droits y afférant, etc.

Cela veut dire qu'on se retrouve avec des tables système assez 
gigantesques pour lesquelles on va se retrouver avec des problèmes 
d'optimisation qu'on ne peut maîtriser puisque c'est justement le moteur 
qui y accède.

Le simple calcul de plan d'exécution SQL risque de représenter une 
charge énorme.

Si on a 10000 utilisateurs en environnement professionnel, cela veut 
sans doute dire qu'on travaille environ à 100 utilisateurs simultanés, 
ce qui nécessite une réactivité excellente.

Dans ce cas, les bons principes de dénormalisation tendent, je crois, à 
privilégier la limitation drastique du nombre de tables.

De plus, les bonnes vieilles formes normales tendent, sauf erreur de ma 
part, à préconiser que s'il y a identité de structure et de sémantique, 
il y a sans doute identité d'entité, non ?

Bien sûr, il faudrait avoir plus d'informations sur ton besoin et sur 
l'utilisation qui en sera faite, mais je pencherais pour un attribut 
"userid" dans chaque table, avec une paire d'index bien léchés.

Mathieu Ignacio a écrit :
> Stéphane Schildknecht wrote:
> > Pourquoi 4 tables ?
> C'est juste une estimation de ma part avec mon gros pif, peut-être 3 ou 
> 6. Bref, pas une appli très complexe.

Ca, pour le coup, ça me surprend beaucoup. Une appli simple, en général, 
a du mal à rester en-deçà d'une vingtaine de tables en raison des 
besoins en informations transversales (utilisateurs, groupes, tables de 
référence, j'en passe et des meilleures).

As-tu fait une esquisse de modèle de données ?
Peux-tu faire passer un fichier DBDesigner par exemple ?

> > Pourquoi le choix du SGBD aurait-il un impact sur la conception du 
> > produit ?
> ? La réponse me semble tellement évidente que je ne suis pas sûr d'avoir 
> correctement saisie la question pour le coup.

non, là, je pense qu'il s'agit du choix entre plusieurs moteurs de 
*SGBD/R relationnels*, ce qui est tout de même le standard le plus 
courant actuellement...

Dans ce cas, seule l'optimisation fine des requêtes et des tables (ou 
presque) est à réaliser lors de la phase de réalisation.

J'ai bon, là ?

> Quelques réponses parmi plein d'autres :
> - Un SGBD dénué de fonctionnalités de clustering imposera/orientera une 
> architecture matérielle et une conception logicielle différente d'un 
> SGBD avec cluster pour répondre à une forte charge.

Pas si évident, AMHA. Tout dépend du type de charge. Là ou je suis 
actuellement par exemple, nous avons un serveur qui tracte 250 à 300 
requêtes/seconde avec un load average à 2,5, autant dire qu'il se 
balade. Pas besoin de clustering dans ce cas...

> - Des limitations toutes simples de capacité de stockage peuvent nous 
> amener à concevoir le logiciel différemment.

Euh... Le prix du disque a baissé, tu sais ;-)

Enfin moi, ce que j'en dis, hein ?

Cordialement,
begin:vcard
fn:Bernard Choppy
n:Choppy;Bernard
org:BC:
email;internet:choppy AT free.fr
x-mozilla-html:FALSE
version:2.1
end:vcard