Bonjour,
je cherche pour développer un projet, une base de données postgreSQL en ligne, qui permette la connexion distante. Je sais que pour les serveur MySQL, les serveurs mutualisés tel OVH interdisent l'accès distant, et je suppose qu'il en va de même pour postreSQL, non ?

Mon patron est prête à payer jusqu'à 15€ par mois pour cette bdd, mais gratuit serait le mieux pour l'instant. Après avoir pas mal cherché, j'ai vu que free.fr proposait un hébergement avec postgreSQL, mais je ne sais pas si il permet l'accès distant ...

J'ai aussi trouvé ceci: http://www.arsys.fr/hebergement/heberg [...] ostgresql.htm
mais les prix sont exorbitants

Merci d'avance.

EDIT

Si vraiment c'est trop difficile à trouvé, je pourrait peut-être utiliser MySQL, donc si vous connaissez des offre pour MySQL ...

je connais le site http://www.db4free.net/d4f_db4free.php , mais il est beaucoup trop surchargé ... il faut quelque fois attendre près de 30 secondes pour établir une connexion ...

> Mon patron est prête à payer jusqu'à 15€ par mois pour cette bdd

C'est le prix d'un kimsufi sur lequel tu peux installer ta BDD.

oui enfin, 15€ c'est le maximum, je croyais que ça pouvais se trouvé à 3 ou 4€ par mois puisque qu'un trouve des offres d'hébergement de qualité à ce prix ...

Bonjour,

C'est vraiment une boite pourri si ton patron n'est pas capable de te filer un accès sur un de ses serveurs...

++

beaucoup de serveur dont OVH le font, question de sécurité à ce qu'il paraît ?!

salut,

pour mes essais je bricole avec free (pas la peine de payer pour un truc pas encore en ligne)

mais pour apres, j'ai vu planethoster.net qui a l'air pas mal pour l'hebergement mais savoir si ils autorisent l'acces distant ... j'ai pas creusé jusque la

voili voilou

15€ ça représente combien d'heures de ton boulot (en coût pour la boîte) ?

AMHA le temps que t'es payé à essayer d'économiser les 15€ coûte plus cher à la boîte que les 15€...

euh ouais, quand je dit mon patron, c'est un projet entre ami, j'ai dit ça pour dire que c'est pas moi qui paye, mais moi je ne suis pas payé. Mais ce que tu dis est vrai, c'est juste que ça me dérange de prendre un kimsufi pour un petit projet en lancement ...

Mais je crois que c'est ce qu'on va faire, merci.
Au passage, j'abord un autre point de la question: C'est un projet pédagogique, ou les statistiques des élèves sont enregistrées dans la bdd. Pour donner un exemple, le logiciel à été testé dans une petite école privée cette année, avec 5 élèves, depuis 6 mois. Et là, j'ai déjà 16 000 lignes dans cette table. Tout ça pour dire, le serveur PostgreSQL en ligne, c'est pour centralisé les données. Et la question, c'est: Faut-il mettre toutes les statistiques de tous les utilisateur du logiciel dans une même table ? En imaginant que l'effectif soit de 500 élèves (ce qui pourrait augmenter considérablement si le projet marche bien), et que les stats sont réinitialisées chaque année, ça fait dans les 300 000 entrées.

J'entends déjà les ricanements de certains, mais je voudrais juste savoir si il y a beaucoup de différence à l'exécution d'une requête très lourde, c'est à dire avec des jointures, des sous requêtes et des GROUP BY, quand la table contient 300 000 lignes ou 30 000 ? J'imagine qu'il y a tout de même une différence ?

Merci beaucoup.

Une requête d'agrégation doit examiner au minimum toutes les lignes qu'elle, euh, doit examiner... genre si tu fais un avg() il faut bien regarder toutes les valeurs dont tu veux faire la moyenne, et bien sûr plus il y en a, plus c'est lent. Les index servent à éviter d'examiner des lignes inutiles (filtrées par le WHERE) mais si tu fais un avg(), un count() ou un sum() sur 30000 lignes, ça sera toujours plus lent que sur 2 lignes.

Donc pour la performance des requêtes d'agrégation, ce qu'il faut regarder n'est pas le nombre de lignes de résultat mais le nombre de lignes examinées pour réaliser l'agrégation. Si tu fais une moyenne des notes d'un gus, étant humain il n'a pas passé 15000 examens dans l'année, donc le nombre de lignes à examiner est réduit, donc même si la table est grosse, si t'as l'index qui cible les bonnes lignes, ça va. Si tu calcules les moyennes de tous les gus pour sortir les 5 meilleurs par contre, c'est une autre histoire.

Remplis une BDD de test avec des données de test en quantité et distribution statistique représentative de ce que tu attends en conditions réelles (un INSERT INTO... SELECT une expression avec random() ou n FROM generate_series(1,N) AS n est utile), puis envoie un VACUUM ANALYZE et teste tes requêtes.

Tu peux envisager :

- le partitionnement (par exemple par année scolaire)
- la matérialisation d'agrégats (par exemple garder la moyenne de chaque gus par matière dans une table à part, et la moyenne générale dans une autre table, etc) ce qui te permet de ne pas avoir à les recalculer
- de te renseigner sur les stratégies de "data warehouse" (attention, c'est violent).

ok, merci beaucoup ...
dernier point: en SQLite, si une table est très lourde, cela va ralentir les autres (au plus le fichier est gros au plus c'est lourd). Je suppose que les SGBD géants comme MySQL ou PostgreSQL n'ont pas le même comportement ? Ah oui aussi, es-ce que tu penses qu'il y a une différence notable entre PostgreSQL et MySQL ? Qu'es-ce que tu choisirais à ma place ? Je ne connais pas trop ces deux là, j'ai juste ouï dire que PostgreSQL est réputé plus puissant ...

> Je suppose que les SGBD géants comme MySQL ou PostgreSQL n'ont
> pas le même comportement ?

Non (et sqlite n'est pas fait pour envoyer de la grosse BDD).

> j'ai juste ouï dire que PostgreSQL est réputé plus puissant ...

Y'a pas photo, surtout sur des requêtes compliquées, l' "optimiseur" de mysql est un moignon de petit doigt arthritique...

ok, d'accord, et ça ne m'étonne pas plus que ça.
De plus, PostgreSQL respecte beaucoup mieux les normes du SQL (90 % je crois).
On m'a beaucoup vanté ses triggers et ses requête fenestrées (si je me souviens bien du terme).

Merci pour tout !