Re: [TECH] Limitation mysql

[Mathieu Ignacio <mathieu.ignacio AT gmail.com>]

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.

> Tu dis que l'appli n'est pas encore conçue, tout reste donc encore
> possible, peut-être même l'utilisation d'une application existante, non ?
Presque :-), y'a des parties assez spécifiques qui font qu'il est très 
probablement plus simple de refaire from scratch, que de reprendre une 
appli existante et la modifier car cela nécessite de la maitriser pour 
bien faire les modifs.


> Même si j'ai une nette préférence pour les éléphants, je ne discute pas
> le choix du SGBD, mais je me demande en quoi ce doit être un pré-requis.
De mon coté, j'ai acquis une expérience sur mysql qui, à défaut d'être 
extraordinaire, me permet d'être autonome et à jour. Je n'ai pas touché 
PG depuis 2001, je me vois mal entamer un projet sur un système que je 
ne maitrise plus du tout.

> 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.
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.
- Des limitations toutes simples de capacité de stockage peuvent nous 
amener à concevoir le logiciel différemment.
- Ou encore utiliser un SGBD basé sur une autre norme que le SQL 
pourrait largement influer sur la conception du produit


Sinon, je veux bien que tu reviennes sur le problème de conception, tu 
pensais à quoi ?


Salut, a+.


> SAS
>
> Mathieu Ignacio a écrit :
> > Stéphane Schildknecht wrote:
> > > Bonjour,
> > >
> > > J'ai comme un vague sentiment qu'il y a un problème de conception
> > > sous-jacent...
> > >
> > > Stéphane
> >
> > Pas nécessairement. L'appli n'étant pas encore conçue, je me pose la
> > question des limites de mysql afin de voir le meilleur choix. Une
> > autre solution est d'ajouter un champs dans les tables afin de séparer
> > les instances et donc d'avoir 1 bd avec seulement 4 tables qui
> > contiennent tout. Cette dernière solution me plait en tant que
> > développeur, mais gêne considéralement l'admin système/technicien
> > d'exploit qui sommeille en moi :-) . Si tu as d'autres pistes, je suis
> > preneur ! (il est exclu que j'utilise autre chose que mysql car je
> > n'ai plus le temps de me former)
> >
> >
> > Merci. a+.
> >
> > ------------------------------------------------------------------------
> >
> >
> >   


--
Mathieu Ignacio,
* mignacio AT nospam.april.org
* http://pydhcplib.tuxfamily.org/
* http://www.anemon.org/