Bonjour.

Chez les différents hébergeurs les tailles de bases MySql sont-elles
estimées de la même façon ?

Parce qu'en regardant une offre qui propose 300 Mo d'espace disque la
taille des bases Mysql ( 2 ) est de 15 Mo chacune. Si ne sont compté dans
la taille de la base que les index, ça va ça laisse de la marge, par contre
si cela comprends aussi les données, je m'interroge ... Comment faire
rentrer mes environs 200 Mo de photos de pages statiques que j'aimerais
bien convertir en pages dynamiques Php+MySql.

Des idées ? Merci.

--
Le Philo - Pssiittttt : Buvez la potion pour me répondre -

Le Philo wrote:

> Bonjour.
>
> Chez les différents hébergeurs les tailles de bases MySql sont-elles
> estimées de la même façon ?
Certains les comptent dans le forfait total, d'autres les comptent
séparément.
>
> Parce qu'en regardant une offre qui propose 300 Mo d'espace disque la
> taille des bases Mysql ( 2 ) est de 15 Mo chacune. Si ne sont compté dans
> la taille de la base que les index
Je doute que l'hébergeur accepte votre interprétation !

> , ça va ça laisse de la marge, par
> contre si cela comprends aussi les données, je m'interroge ... Comment
> faire rentrer mes environs 200 Mo de photos de pages statiques que
> j'aimerais bien convertir en pages dynamiques Php+MySql.

En prenant une offre au-dessus, on un hébergeur moins regardant sur la
taille de la BD.

Christophe Baegert wrote:

>>contre si cela comprends aussi les données, je m'interroge ... Comment
>>faire rentrer mes environs 200 Mo de photos de pages statiques que
>>j'aimerais bien convertir en pages dynamiques Php+MySql.
> En prenant une offre au-dessus, on un hébergeur moins regardant sur la
> taille de la BD.

Ou en ne codant pas avec les pieds. La base stocke les meta-data, et les
photos elle memes sont stockées sur disque.

--
Thomas

Le mer, 27 jui 2005 at 13:46 GMT, Le Philo <lephilo@druidie-potion.org> a écrit:
> Chez les différents hébergeurs les tailles de bases MySql sont-elles
> estimées de la même façon ?

Plus ou moins.

> Parce qu'en regardant une offre qui propose 300 Mo d'espace disque la
> taille des bases Mysql ( 2 ) est de 15 Mo chacune.

Certains vont compter les bases dans l'espace total. Pour d'autres, ça
sera une partie prédéfinie (comme le cas que tu décris). Pour encore
d'autres, ça peut être un abonnement spécifique.

> Si ne sont compté dans la taille de la base que les index,

Et dans les quotas de mail, on ne va compter que les entetes, aussi....

> ça va ça laisse de la marge, par contre si cela comprends aussi les
> données, je m'interroge ... Comment faire rentrer mes environs 200 Mo
> de photos de pages statiques que j'aimerais bien convertir en pages
> dynamiques Php+MySql.

Tu fais (ou utilises) une application qui ne soit pas toute pourrie et
ne stocke pas les images dans la base de données.


Dom

Thomas Pedoussaut <thomas@parinux.org> wrote:

> Ou en ne codant pas avec les pieds. La base stocke les meta-data, et les
> photos elle memes sont stockées sur disque.

Cette soluce me semble effectivement plus cohérente.

Question corolaire : Des outils style Coppermine ou Gallery codent-ils
comme des pieds ? ;-) Ou vont-ils se contenter de mettre les méta-data
en base.

--
Le Philo http://druidie.org
Pssiittt : Buver la potion pour me répondre

Dominique ROUSSEAU <domi@nerim.net> wrote:

> > Si ne sont compté dans la taille de la base que les index,
>
> Et dans les quotas de mail, on ne va compter que les entetes, aussi....

Effectivement, index était un peu réducteur ;-)
Méta-data convient mieux. Si on entend par là, descripstion de l'image,
caractérisation, commentaires, emplacement.

reste plus qu'à utiliser ou faire l'appli qui va bien.

--
Le Philo http://druidie.org
Pssiittt : Buver la potion pour me répondre

Le mer, 27 jui 2005 at 15:47 GMT, Le Philo <lephilo@druidie-potion.org> a écrit:
> Thomas Pedoussaut <thomas@parinux.org> wrote:
>> Ou en ne codant pas avec les pieds. La base stocke les meta-data, et les
>> photos elle memes sont stockées sur disque.
>
> Cette soluce me semble effectivement plus cohérente.
>
> Question corolaire : Des outils style Coppermine ou Gallery codent-ils
> comme des pieds ? ;-) Ou vont-ils se contenter de mettre les méta-data
> en base.

Pour Copermine, je ne sais pas, mais la version 1 de Gallery fonctionne
sans bdd, ça m'étonnerait qu'ils se soient mis à ranger les photos en
base dans les version suivantes

Le Wed, 27 Jul 2005 17:34:16 +0200, Dominique ROUSSEAU a écrit :
> Tu fais (ou utilises) une application qui ne soit pas toute pourrie et
> ne stocke pas les images dans la base de données.

Stocker du binaire (ex: des images) dans une base de données, même
relationnelle, ce n'est pas forcément tout pourri. Il y a des avantages
(ex: simplification des sauvegardes, tout est dans la base, ou
centralisation - nécessaire si plusieurs frontend - et nommage unique
des objets, ainsi qu'API à peu près unique puisque tout passe par le
SGBDR) et des inconvénients (base de données pas forcément adaptée à
ca, données perçues comme opaque[1], taille), mais les ``binary large
objects'' ont bien été inventé dans les SGBDR pour ca. Donc ca répond
à un besoin.

Il est clair par contre que là cela peut être une solution (de mettre
les images en dehors), vu les quotas mis en place par l'hébergeur.

Le reste de la discussion, si nécessaire, dans fr.comp.applications.sgbd

[1] on aurait pu tenir la même discussion sur, par exemple, un fichier
XML (non binaire), pour lequel on peut arguer qu'il n'a pas sa place dans
un SGBDR qui ne le percoit que comme une chaîne de caractères...
jusqu'à ce que les SGBDR ajoutent une couche XML et soient capables de
gérer des instructions XPATH dans un SELECT par exemple.
On peut imaginer un SGBDR (via une extension par exemple), qui soit
capable d'extraire, dans un SELECT et avec une procédure stockée, les
informations EXIF d'un bloc binaire stocké qui correspond en fait à une
image.
Etc...

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>