Précédent   Forum du club des développeurs et IT Pro > Bases de données > PostgreSQL
PostgreSQL Forum PostgreSQL. Avant de poster -> F.A.Q PostGreSQL Tutoriels PostGreSQL
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse
 
Outils de la discussion
Publicité
'
Vieux 08/02/2009, 20h51   #1
Djug
Rédacteur
 
Avatar de Djug
 
Homme
Inscription : mai 2007
Messages : 3 180
Détails du profil
Informations personnelles :
Sexe : Homme
Âge : 26
Localisation : Algérie

Informations forums :
Inscription : mai 2007
Messages : 3 180
Points : 19 506
Points : 19 506
Par défaut Votre avis sur PosgtreSQL ?

Bonsoir à tous

Pourriez-vous nous donner votre avis sur PostgreSQL ? Qu'en pensez-vous en tant qu'utilisateur, développeur, administrateur ? Merci de donner de nombreux détails :
  • le type d'utilisation (systématique, réfléchie, selon le client, etc.) ;
  • la taille moyenne de vos bases de données (estimation) ;
  • quel avis a eu le plus de poids lors de la décision (le développeur, l'administrateur etc.) ;
  • langage(s) de programmation utilisé(s) pour les applications ;
  • et toute information supplémentaire qui vous semble utile !

__________________
Tweet more than 140 characters with long-tweets.com

Tutoriels JADE (Java Agent DEvelopment Framework)
http://djug.developpez.com

Je ne réponds pas aux questions techniques par Messages privés: les forums sont faits pour ça
Djug est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 09/02/2009, 08h57   #2
scheu
Membre Expert
 
Avatar de scheu
 
Inscription : juin 2007
Messages : 1 501
Détails du profil
Informations forums :
Inscription : juin 2007
Messages : 1 501
Points : 1 493
Points : 1 493
1) Utilisation en production sur des applications web ou de petites applications type transactionnel (OLAP)
2) plusieurs dizaines de Go (40 Go pour la plus grosse)
3) le DSI et aussi le DBA qui a pu donner son avis, en tout les cas le choix a été Postgresql plutôt que MySQL (sans regrets ) pour sa capacité à gérer la montée en charge, le respect de la norme SQL, le langage procédural PL/PgSQL, et les fonctionnalités de haute-dispo (notamment le log shipping)
__________________
La théorie, c'est quand on sait tout mais que rien ne fonctionne.
La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/
scheu est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 09/02/2009, 15h31   #3
rupteur
Membre habitué
 
Homme Eric
Informaticien
Inscription : juin 2004
Messages : 121
Détails du profil
Informations personnelles :
Nom : Homme Eric
Localisation : France

Informations professionnelles :
Activité : Informaticien
Secteur : Agroalimentaire - Agriculture

Informations forums :
Inscription : juin 2004
Messages : 121
Points : 116
Points : 116
En production

1) 1 base de 4Go pour un serveur web/php
2) 1 base de 2Go pour un serveur attaqué par du java/jasper report

Les deux bases sont appelées à grossir (volumétrie minimum 20Go)

3) Décision prise par le chef de projet,l'administrateur,le développeur... (c.a.d la même personne car petite structure)
le coût, la robustesse,le respect sql, les extensions(ex: postgis) ont contribués au choix.

4) Fiable (pas de problème depuis 2 ans) et très peu d'entretien, juste un vacuum lancé la nuit par un cron avant un pg_dump de sauvegarde.

5) Pas de souci lors des développements avec php,java et jasper(ireport).
rupteur est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 28/02/2013, 21h19   #4
el_muchacho
Nouveau Membre du Club
 
Homme
Inscription : février 2013
Messages : 23
Détails du profil
Informations personnelles :
Sexe : Homme

Informations forums :
Inscription : février 2013
Messages : 23
Points : 29
Points : 29
Notre appli intègre Postgres 9.1 et la base doit grossir à hauteur de 1To environ chez nos clients. Pour l'instant, après un an de bons et loyaux services, absolument aucun reproche à lui faire, Postgres n'a posé aucun soucis.
el_muchacho est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 01/03/2013, 13h47   #5
SQLpro
Rédacteur

 
Avatar de SQLpro
 
Homme Frédéric BROUARD
Expert SGBDR & SQL
Inscription : mai 2002
Messages : 12 080
Détails du profil
Informations personnelles :
Nom : Homme Frédéric BROUARD
Localisation : France

Informations professionnelles :
Activité : Expert SGBDR & SQL
Secteur : Conseil

Informations forums :
Inscription : mai 2002
Messages : 12 080
Points : 21 678
Points : 21 678
Citation:
Envoyé par Djug Voir le message
Bonsoir à tous

Pourriez-vous nous donner votre avis sur PostgreSQL ? Qu'en pensez-vous en tant qu'utilisateur, développeur, administrateur ? Merci de donner de nombreux détails :
  • le type d'utilisation (systématique, réfléchie, selon le client, etc.) ;
Beaucoup trop systématique... et rarement réfléchie !
On veut du libre...
j'ai des clients qui travaille sur du SQL Server alors qu'ils pourraient parfaitement utiliser du PG.
Inversement certains clients arrivent à des impasses avec PG alors qu'en choisissant SQL Server, il aurait solutionner leurs problèmes à moindre coût.
En effet PG n'est pas taillé pour :
- une forte concurrence (en pratique plusieurs centaines d'utilisateur c'est pas possible, sauf si lecture seule, la gestion du journal des transactions est loin d'être optimal, enfin PostGreSQL n'est pas MultiThread).
- une forte volumétrie (en pratique PG n'est pas taillé pour supporter plusieurs To (pas de gestion des espaces de stockage, partitionnement inepte...)
- la BI : pas de mécanisme de compression des données ni de précalcul des agrégats (vue matérialisées ou indexées), pas de stockage vertical (columnstore index par exemple)
- des services particuliers de données : le DATALINK par exemple, voir ce thread :http://www.developpez.net/forums/d13...s/#post7154500)
Et même certaines requêtes SQL pourtant classiques, sont infaisable sous PostGreSQL. A me lire : http://blog.developpez.com/sqlpro/p1...bd_relationn_1

Citation:
  • la taille moyenne de vos bases de données (estimation) ;
Le bon coin utilise une BD de plus de 1 To, mais cela reste très exceptionnel.
Les CAF utilisent des bases départementalisées, mais elle ne sont pas de très grande tailles (au plus une centaine de Go)*
La Préfecture de Police utilise des bases PG de taille moyenne (quelques dizaines à quelques centaines de Go).

Citation:
  • quel avis a eu le plus de poids lors de la décision (le développeur, l'administrateur etc.) ;
Le free... pas de licence à payer... Ce qui peut se retourner en cout supplémentaires exorbitant du fait des manques fonctionnels.
Ainsi à la D DE du Gard nous sommes passé de PG à SQL Server pour des raisons simples :
pas de vues indexées (donc temps de réponse immonde, sauf à mettre une machine très couteuse pour pallier ce problème.
pas de mécanisme de haute dispo synchrone, sauf à jouer sur le hardware et là encore cout exorbitant
Et quand il a fallut leur dire que SQL Server revenait environ 5 fois moins cher que PG, le ministère à du s'y reprendre à deux fois avant de se contredire et accepter la facture finale !

Citation:
  • langage(s) de programmation utilisé(s) pour les applications ;
Tous les langages sont plus ou moins valable et ont avantages et inconvénient...
PHP est populaire et de bon niveau. .net (C# en particulier) devance aujourd'hui largement Java en termes fonctionnel, praticité et performances...
Évitez par contre l'utilisation des ORM pour la montée en charge. C'est une plaie. A lire : http://img1.lemondeinformatique.fr/f...s-epaisses.pdf

Citation:
  • et toute information supplémentaire qui vous semble utile !
Toujours commencer par une étude d'adéquation entre l'outil et la demande. Le TCO peut être en faveur de PG comme en défaveur. Les manques de PG sont énormes par rapport à des outils comme Oracle ou SQL Server (BI, reporting, haute dispo...). Dans ces cas, la plupart du temps les offres commerciales sont largement gagnante, car remplacer un truc inexistant dans PG par de l'huile de coude, coute non seulement l'huile de coude elle même, mais la maintenance et les évolution de cette huile de coude...ce que beaucoup de décideur oublient ou ignorent !

A +
__________________
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
* * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
SQLpro est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse
Outils de la discussion

Navigation rapide


Fuseau horaire GMT +2. Il est actuellement 02h02.


 
 
 
 
Partenaires

Hébergement Web