Bonjour,
je suis actuelement sur un projet de base de donnée qui sera mis a jour par plusieur personne situé sur des sites differents, ce sera une interface web php.
 
Je suis a la recherche de complement d'information sur le mysql et le postgre afin de savoir lequel correspondrai le mieux aux attentes de la boite ou j'effectu mon stage.
 
J'hesite entre ces deux base de données et Oracle XE (version gratuite) mais la capacité de cette derniere est limitée à 4Go.
 
J'attend vos eventuels conseils, merci d'avance.

Fonctionnellement parlant, PostGre reprend au moins autant de fonctionnalités qu'Oracle.
 
MySQL, quant à lui, n'en reprend même pas le dixième.
 
En revance, MySQL est bien plus rapide et facile d'administration.
 
Pour le reste... Ca reste tous deux de bons SGBD.
 
PS : 4 Go, c'est vraiment une limitation pour ton truc ? T'es sûr ?
 
Ici je suis chez un client qui utilise un ERP, avec des centaines de commandes saisies chaque jour, et au bout de 5 ans ils ont dépassé les 2 Go de données durant l'été...
 
Alors je crois que ça te laisse de la marge !

Merci, je te remerci pour ta reponse, je t'avoue que cela m'éclaire déja un peut,
cela j'aimerais savoir ce que tu me conseil,
sachant que l'entreprise souhaite créer une base de données contenant plus de 50 tables, devant etre disponible en ligne en lecture et ecriture,
elle dois aussi etre mis en relation avec une autre base de données de gestion et partage de documents.
 
Sachant que mysql s'arrete à 61 tables, par contre je ne sais pas a combien s'arrete POSTGRESQL.
J'aimerais egalement avoir des infos sur ORACLE XE si tu en as.
 
Merci d'avance.
 

que 61 tables dans MySQL ???
 
T'es sûr ? Parceque je trouve ça... comment dire... euh...
 
Sinon, moi je conseille SQL Server 2005 Entreprise mais c'est payant
Mais au moins il est blindé de doc, claire et facile d'accès.
 
A défaut, PostGre est l'équivalent à SQL Server ou Oracle, mais avec une doc bien moins accessible (écrite par des geeks autistes pour des geeks autistes si tu préfères). Mais tu ne rencontrera aucune limite avec.
 
Dans tous les cas, 50 tables, base de documents... Rassure-moi, les documents sont pas stockés DANS les tables si ?
 
Parceque si c'est pas le cas, t'aura saturé une baie de disques de 1000 To avant d'avoir rempli une base de 4 Go hein...

J'ai oublier de te dire qu'il veulent une solution open source et gratuite.
 
Ensuite les documents ne seront pas stocker dans la BD, ca sur.
Les 50 tables font parti d'une base de données et la base de document est apart c pas la meme base. CETTderniere sera sur POSTGRE, mais ca ce n'est pas de mon ressort.
 
Donc toi, tu me conseil postgre sql ? et oracle 10 Express ?

Si tu dois t'interfacer avec une base PostGre, alors je te conseille PostGre, pour deux raisons principales :
1/ Tu pourras faire des DBLINK d'une base à l'autre sans problème (possible en mélangeant les SGBD, mais c'est s'exposer à des problèmes)
2/ N'importe qui qui a travaillé sur un système pourra filé un coup de main sur l'autre système. C'est pas négligeable, surtout pour le DBA qui va devoir maintenir les deux bases... Et surtout, ça lui permet d'héberger les deux bases sur la même machine !

 
eXACT CE sont des choses aux quel j'ai penser mais pour le moment les deux seul choses ki me freine un peut sur mon choix definitif, cest que je ne trouve aucune doc bien faite pour interfacer php/postgre et que je ne sais pas si ORACLE 10 express ne serai pas mieux sachant que c oracle et que c gratuit.
 
Je te remerci pour tes conceil j'en tiendrai compte lors de ma decision.
 
a bientot

foutaise et fud.
 
http://www.postgresqlfr.org/?q=node/1432

 
C'est sympa que tu reponde, mais peux tu argumenter, ici nous sommes civilisés, merci d'avance,
en attendant ta reponse.

dedooz > T'as dû chercher loin
http://www.manuelphp.com/php/ref.pgsql.php
 
taz > ouais, et sur mysql.com, t'as l'article opposé.
 
chez oracle on dit qu'on est mieux que chez microsoft, et chez microsoft on dit l'inverse.
 
forcément, si tu compares des procédures stockées faisant appel à des transactions de façon intensives, deux domaines neufs sous mysql et pas encore optmisés, tu vas exploser mysql avec postgre.
mais pour une utilisation courante, genre insertions et selections unitaires sans transactions, postgre est à la rue, c'est toujours autant le cas aujourd'hui qu'il y a 5 ans (surtout si avec mysql tu choisi un format de fichier non transactionnel)
 
globalement, les perfs de mysql, pour 99% de l'utilisation d'un sgbd, sont suppérieures à postgre. ça ne remet pas pour autant en cause sa montée en charge ou ses capacités. c'est un fait. une requête d'insertion de 100 000 lignes qui prends 0,001 seconde, sous postgre c'est impossible. sous mysql, on trouve ça très lent.
 
après y'a aussi des domaines où windows est mieux que linux, sisi, en cherchant bien ça doit se trouver.

la limite de 61 tables sous mysql est fausse, un typo3 (cms) avec 2-3 plugins ça t'en fait facilement le double

mais qu'est-ce que je fous ici à discuter avec un type d'un produit qu'il a tellement utilisé qu'il ne sait même pas l'orthographier ?

tu discutes pas, t'essayes juste de descendre systematiquement magic, discuter c'est avoir un dialogue sissi

merci casimimir, tout est dit

 
yo Harko

ouais c'est tout à fait ça. Je file un lien intéressant et la seule réponse que j'ai d'une personne qui n'a jamais utilisé postgres c'est "les autres disent le contraire et ils ont raison". Personne qui si elle lisait un peu l'article comprendrait qu'il n'est pas question de comparées des requêtes tordues mais bien de propriétés fondamentales d'un SGBDR. Magic nous annonce des chiffres délirants et mythomanes sur des histoires d'insertion de "100 000 lignes qui prends 0,001 seconde". Il en vient à nous conseiller sa daube de SQLWormServer. Enfin il nous explique que "A défaut, PostGre est l'équivalent à SQL Server ou Oracle, mais avec une doc bien moins accessible (écrite par des geeks autistes pour des geeks autistes si tu préfères)." ce qui est finalement assez vrai dans la mesure où si tu ne sais pas orthographier le produit, tu risques d'avoir du mal à trouver la doc.

Salut, au depart j'ai poster cette article pour avoir un comparatif entre MYSQL et POSTGRESQL, merci de revenir au sujet d'origine. Merci d'avance

Donc le lien que j'ai posté est pas mal notamment à propos des propriétés ACID / fiabilité.
 
Sinon niveau perfs, l'un ou l'autre, tu seras satisfait. Je parle en tant qu'admin pg: la conf est très simple, la documentation est excellente. Les outils et le support complet des transactions permettent de faire du très bon travail notemment backup et MAJ de schéma (atomicité).

 
Ok merci pour cette réponse, maintenant que j'ai eliminé Mysql de mon choix car il ne correspond pas asser a ce ke je recherche,
par contre ya deux nouveau ki sont en lisse,
SQL SERVER 2005 ET ORACLE 10 XE,
 
je ne sais aps trop vu que se sont des version moin puissante que leur version payante, si elles seront a la hauteur des attente de l'entreprise.
 
Que pensez vous de ces deux SGBD ?

Laisse tomber Oracle, à moins que tu sois accro :
- aux erreurs aléatoires injustifiées (bonjour les ORA-01031 en étant loggé en SYS)
- à l'administration lourdingue et d'un autre age (quand on voit la gueule de SQL*PLUS, franchement... proposer un tel outil en 2007 est une honte)
- au déploiement bloaté et d'une lourdeur éléphantesque
- au PL/SQL bien pourri (vive les PS en C# de SQL Server 2005)
- ...

Je sais qu"ORACLE possède certaines faille, mais ça reste quand même la référence, je veux juste savoir si ORACLE 10 XE et SQL Server 2005 Expresse sont des SGBDs de qualité et si PostGreSQL peut les remplacer sans grandes différences.

Oracle est certes une référence, mais une référence Commerciale et pas Technique, tu saisis la nuance ? C'est pas parce qu'un produit est leader que c'est forcément le meilleur, c'est juste qu'il est mieux vendu.
Ceci étant dit, j'avoue ma préférence pour SQL Server Express. Mais ni l'un ni l'autre ne rentrent dans tes critères car comme tu le dis toi même, tu cherches une solution Open Source ce que ni l'un ni l'autre sont.
Donc pour toi, point de salut : PostgreSQL te tend les bras.

Vas-y les déformations. Arrête de lire en diagonale mes posts avant de me faire dire ce que je n'ai pas dit.
 
Chaque produit proclame haut et fort qu'il est le meilleur, donc ton lien n'est pas "fiable" c'est tout ce que j'ai dis dans mon post.
Il n'en reste pas moins qu'il peut être intéressant, jamais dit le contraire.
 
Par contre, tu noteras quand même que l'article stipule lui-même que les tests sur lesquels il se base ne supportent pas de comparaisons : matériel différent, conditions de test différentes, etc. Et du coup il est principalement théorique.
PostGres avec un S si ça te fait tant plaisir, a bien évolué, et c'est tant mieux, mais il n'y a guère plus de choses à en retenir.
J'aime surtout la petite éloge d'Oracle d'un point de vue rapidité, etc. Si PostGres est comparable à MySQL sur ce point, alors tu peux mettre de côté Oracle, qui est très loin derrière.
Le seul atout d'Oracle d'un point de vue performances, c'est sa montée en charge qui est exemplaire. Pour le reste, il est très lent comparé à MySQL.
La moindre requête du genre "select 1 from dual" prends systématiquement 5 à 10 ms.
Autant sur de très grosses requêtes concurrentielles dans de grosses transactions, il va tirer son épingle du jeu, autant pour la moindre petite requête (et c'est quand même ce genre de requêtes qui sont les plus utilisées) c'est incoparablement plus lent. Donc selon l'utilisation, généralement Oracle n'offira clairement pas le même niveau de performances (transa-quoi déjà ?)
 
Enfin, pour reprendre l'article en question, il est spécifié que le test de MySQL est effectué avec la version 5.0
Et c'est rigoureusement ce que j'ai répondu. La 5.0, c'est plus une béta qu'une version d'exploitation. Elle apporte plein de nouveautés (vues, PS, triggers, etc.) mais absolument rien n'a encore passé la phase d'optimisation : ça marche, et c'est déjà ça. Un très grand nombre de gens s'en sont d'ailleurs plainds, et la version 5.1 était très attendue.
Pour cette raison, une comparaison avec la 5.1 ou une 4.x aurait été bien plus parlante, puisque MySQL n'est plus aussi désavantagé avec cette version (ceci dit, comparer PostGres à MySQL < 5, c'est une insulte pour PostGre).
 
Au fait, Christophe Chauvet alias KrysKool, cité en fin d'article, n'est ni plus ni moins qu'un de mes collègues. On en discute suffisament comme ça à chaque fois que je le dépanne sous SQL Server pour que je sâche un minimum de quoi je parle.

Non, ça n'est pas mieux du tout. Oracle XE ne sert que pour le développement sous Oracle. Autrement dit, il est utile si ta compagnie a déjà choisi Oracle. A ce moment-là, il est pratique car on peut déployer un Oracle XE sur son poste pour développer, au lieu d'acheter une licence (hors de prix, comme tout chez Oracle) et un serveur dédié à partager entre devs.
Pour la production, il ne faut pas compter dessus, il est quasi inutilisable, avec sa limitation à 1 Go de RAM, ce qui réduit certainement considérablement ses performances (sachant qu'XE prend déjà ~400 Mo au démarrage). Il n'y a pas officiellement de limite de connexions simultanées mais la limitation sur la RAM fait offfice de limitation sur le nombre de connexions simultanées. Oracle ne va pas distribuer son produit gratuitement du jour au lendemain, faut pas rêver.
Ah et Oracle est BIEN plus compliqué et casse-burnes à administrer que MySQL ou Postgres. Ok, XE est simple à installer, mais le jour où vous décidez de sortir le portefeuille pour le produit complet, c'est une autre paire de manches. Et à l'utilisation, Oracle réserve effectivement plein de surprises, notamment avec des messages d'erreur d'une infinie variété et qui n'ont strictement rien à voir avec les erreurs qu'ils sont censés montrer (une belle partie de plaisir pour le dev). Ce qui réduit considérablement le "facteur fun" d'Oracle et donc la productivité du développeur. A ne pas négliger quand on va passer quelques années à développer sur un produit.

Franchement, prends Postgres 8 ou MySQL 5 (qui continue à s'améliorer et n'a bien sûr jamais été limité à 61 tables. Le nombre de tables par base est probablement illimité, ou alors un nombre comme 32000). L'un et l'autre logiciels ont largement fait leurs preuves en production. Perso, j'ai une grosse préférence pour Postgres, qui au niveau du développement a quasi autant de fonctionnalités qu'Oracle. En particulier, les procédures stockées sont un accélérateur de développement et surtout de performances que même des données brutes sur des select ne peuvent rattraper (car une PS permet de supprimer tout l'overhead entre ton appli cliente et le moteur de base de données, - à savoir essentiellement de multiples transferts de données sur le réseau, les surcouche applicatives/persistence du client -, vs traitement en RAM dans le cas d'une PS --> on peut obtenir des gains de perfs de x100 ou plus). Par contre autant l'usage massif de PS permet d'augmenter considérablement les perfs (si le serveur dédié est costaud), autant il interdit toute migration vers une autre base à l'avenir.

Si vous optez pour un logiciel commercial, SQL Server est basé sur Sybase, qui est très performant aussi.

Allez, je m'autoquote:

"Oracle Enterprise Manager c'te grosse bouse au nom marketing hypertrophié. Comment je plains Harko

Donc je voulais insérer un nouvel enregistrement à une table existante. Hop, un copier-coller d'une ligne existante, et le tour est joué.
Seulement voilà, quand on insère une date via un bête copier-coller d'une date qui existe, Oracle te sort un beau

Ah, bon. On vérifie, on re-vérifie la date, elle est bonne.
Finalement, un collègue t'explique que t'as tout faux, qu'un copier-coller ne fonctionne pas parce qu'il faut en fait insérer la commande escuelle:
TO_DATE('21-avr. -2006 10:15:00 AM', 'dd-Mon-yyyy HH:MI:SS AM')

Vaincu par la logique implacable de la chose (vu qu'on spécifie le format), on s'exécute patiemment.
 

Mais bien sûr...
 
A nouveau vaincu, mais passablement énervé au bout de 40mn à chercher, on on essaye alors autre chose.
Le machin est censé te sortir la commande SQL qui correspond à une insertion dans un tableau via la supaaaiiiir IHM en Java. Chouette, me dis-je, je n'ai qu'à la recopier dans SQL*Plus, en faisant très attentiion à ne pas me planter vu le degré d'user-friendliness de cet outil, et le tour et joué.

Evidemment, ça ne marche pas. La commande SQL générée par l'outil "Oracle Enterprise Manager" est bourrée d'espaces posés au hasard du genre (copier-coller de la commande générée):

Admirez le placement des espaces avant (!) les virgules. C'est pas beau, ça ? Mais le pire étant les chaînes coupées en plein milieu avec des espaces en début de ligne. Sûr que SQL va apprécier...
Qu'à cela ne tienne, je la recopie dans mon éditeur favori, dégage les CR/LF superflus  et rejoue.

... Reperdu !

Finalement, je m'aperçois que cette daube d'OEM génère une commande fausse, du fait d'une traduction hasardeuse et de tests inexistants chez Oracle.
En effet, "21-avr. -2006" comporte un point et un espace de trop, "24-mai  -2006" a 2 espaces de trop, etc. Evidemment, dans la police sans serif proposée par OEM, c'est à peine visible.

Non mais vraiment...

Actuellement, j'en suis à :

. Surtout ne me dis pas où. "

Pour une bonne tranche de rire, quelques perles:

 
Merci 'el muchacho'
 
Donc si je comprend bien, le choix de PostGres est un choix definitif ? impossible de d'exporter mes bases sur une autre SGBD, il n'y a vraiment aucun moyen ?

Oui et non.
Les Proc stockées de PG sont globalement compatible avec Oracle (enfin selon Harkonnen, à vérifier). Mais de toute façon, une fois qu'on utilise des PS, sauf si elles sont codées dans un langage standard, on peut oublier les portages, parce que PL/SQL (Oracle) et Pg/SQL (PG) sont des langages propriétaires. C'est pour ça que bcp de boîtes codent la logique applicative dans les applis client, ce qui est à mon sens une erreur stratégique, parce que le portage vers une BD même 4x plus rapide rattrapera rarement les pertes de performances dues aux entrées/sorties (et jamais si ça passe par le réseau).
Mais globalement, on peut dire qu'il n'existe pas vraiment 2 bases de données compatibles, parce que très peu supportent le SQL standard. Donc un portage d'une BD vers une autre prendra de toute façon tjrs pas mal de ressources. A ce titre, PG est peut-être la plus standard de toutes car elle supporte intégralement SQL92, ce qui n'est pas le cas d'Oracle, par ex. qui n'est pas standard du tout, - ni même de MySQL -.

Disons que pour la compatibilité Oracle, PG est probablement le meilleur choix (à part Oracle XE évidemment). Après, je préfère laisser la place aux spécialistes BD plutôt que de dire n'importe quoi.

Donc si je veux transférer d'une SGBD  à une autre, faudra exporter les tables et tous reprogrammer, si j'ai bien compris.

changer de sgbd en cours de route, oui, c'est toujours un gros travail.
 
faut pas "tout" refaire, mais en effet y'a pas mal de choses qui ne passent plus, car le support du langage sql n'est jamais éxactement le même d'un sgbd à l'autre (pg est l'outils qui se rapproche le plus de la norme) mais surtout les langages pg/sql, pl/sql, t-sql mar exemple... comme leur nom l'indique, ne sont pas compatibles... ils sont équivalent, structurés de la même façon, mais syntaxiquement différents.
 
donc ça nécessite pas mal de boulot.
 
mais pas autant que de passer par exemple d'un programme écrit en VB à un programme écrit en VB.NET : mise à part la syntaxe, généralement t'as rie à modifier.

Merci, c'est ce que je voulais savoir, car l'entreprise, après mon passage passera peut être à une SGBD sous licence, donc faut prévoir l'exportation au cas ou (un cahier des charges).
 
Je vous remercie vous avez répondu a mes questions, tout devient plus clair, bien sur j'ai fait de recherche en parallèle.
 
Donc je proposerai en premier temps PostGreSQL et je proposerai de passer sous SQL Server si ils veulent passer sous licence.
 
Merci encore ...

Autres frais à prévoir pour l'entreprise : un DBA à plein temps.  
Une base de données ça demande du travail à maintenir, et le monde de l'administration est très différent de celui du développeur.
 
Côté SGBD payant y a Sybase qui est pas mal aussi, en tout cas c'est ce qui est utilisé chez nous et c'est solide (par contre ce SGBD souffre également de "concision" lors de problèmes... genre un insert qui foire au milieu, il te dit juste que ça a foiré, pourquoi, mais pas où )

 
Ah ça je sais qu'il faut prévoir un DBA, j'aurai aimé prendre ce poste, mais bon faut voir ce que l'entreprise a comme moyen et si il n'en pas déjà prévu d'embaucher quelqu'un(ce qui m'etonnerais) mais bon ils le savent aussi.
 

 
Au sujet de des problèmes de 'concision' apparemment grand de bases de données en souffre d'après ce que je li depuis l'ouverture de ce topic lol.

C'est pour cette raison que beaucoup de gens aiment SQL Server et MySQL.
Car contrairement à Oracle surtout, et PostGres (à moins que ça ait changé), ils ne nécessitent que très peu de paramétrage, beaucoup de choses étant automatisées par défaut, et les paramètres par défaut étant généralement suffisants pour avoir un bon compromis entre "compétence de DBA" et "performances du serveur".
Oracle, c'est l'horreur, puisque par exemple il ne sait pas redimensionner automatiquement un tablespace : crash assuré plusieurs mois/années après mise en place, sans que personne n'aie la moindre idée du pourquoi du comment.
Pour PostGres, il fallait à l'époque autant de boulot que pour Oracle afin d'obtenir un truc stable et performant. Je ne sais pas si ça a évolué depuis.

http://www.powerpostgresql.com/Docs/
Performance Whack-a-Mole
5 steps to PgSQL Performance