Bon, Oracle, c'est ce qui se fait de mieux, mais c'est pas libre, et surtout c'est cher !
 
donc je cherche du coté des SGBD libre
 
Je connaissais MySQL (de nom), et je viens de tomber sur PostgreSQL.
 
Je voudrais savoir s'il y en a d'autres, et quels sont les avantages de Postgre
 
de plus, je viens de voir que MySQL ne gèrait pas les clés étrangères, Postgre le fait ?
Ca pose pas de problèmes de ne pas pouvoir utiliser les clés étrangères avec MySQL : ça doit pas donner une gestion terrible ça, si ?
 
 
PS : j'oubliais le principal. Est-ce que Postgre est disponible chez les hébergeurs (c'est pour une utilisation pro, donc il faut que je sache si Postgre est stable, et adapter à une utilisation pro)
 
merci

alors, y-a bien qq'un qu'a un semblant de réponse à me donner, non ?

       
 
bref.
 
bon je n'ai jamais utilisé postgresql mais ce qu'on en dit il me semble c'est
mysql: tres fort pour gerer les GROSSES bases, et tres rapide
postgresql: bcp plus complet (foreign keys etc)
 
mysql est plus repandu chez les hebergeurs il me semble mais y'a postgresql chez certains
 
qu'il y ait pas de fk dans mysql ça m'a jamais derangé... mais chuis pas une grosse brute en db. je peux checker mes keys dans mon app (pas frapper), et pis c plus facile a maintenir une base sans fk ... enfin bref, à mon avis ça pose aucun pb tant que la base n'est utilisée que par une seule app quoi.
enfin je veux bien qu'on me corrige là dessus, parce que mon avis n'est pas tres pointu... (mais gentiment alors)
 
 

 
je commence à cerner l'utiliter d'une SGBD relationnel (j'ai posté un peu partout ) : en fait, ça permet de rendre la gestion de l'intégrité d'une bdd, indépendamment des appli qui tourne dessus (grand interet si plusieurs appli tourne dessus)
 
sinon, je te confirme, apparemment, seul mysql est utilisé chez les hebergeur

tatanka a écrit a écrit :     je commence à cerner l'utiliter d'une SGBD relationnel (j'ai posté un peu partout ) : en fait, ça permet de rendre la gestion de l'intégrité d'une bdd, indépendamment des appli qui tourne dessus (grand interet si plusieurs appli tourne dessus)

 
ouais et puis ça t'empêche de faire des conneries si tu programme mal ton appli

...sauf si tu construis mal ta db... et si tu programmes mal, y'a des chances que tu construises mal ta db aussi

certes    
mais bon en gros c qd meme une sécurité supplémentaire

je bosse sur PostgreSQL depuis 2 semaines (et je connais MySQL depuis 1 an...)
PostgreSQL, c'est vraiment bcp plus évolué, c'est plus proche des spécifications SQL, donc, c'est mieux. ça a été développé par des chercheurs de l'université de Berkeley.
Les + par rapport à MySQL :
- gestion des clé étrangères
- select imbriqués possibles dans les requêtes
- sequences
- triggers
...
Les - par rapport à MySQL :
- quasi introuvable chez les hébergeurs web
- très chiant à installer un serveur PostgreSQL sous windows (mais très simple sous linux)

 
ça confirme tout ce que je viens d'apprendre depuis que je cherche des infos, sauf pour les triggers !  
mysql ne les gere pas !?
ça fait vraiment rien tout seul en fait, on est obliger d'avoir php/asp ou autres avec
 
 
sinon, on s'en fout de windows

php/asp, mais n'importe koi qui peut utiliser des drivers mysql, comme java

tatanka a écrit a écrit :    les triggers !   mysql ne les gere pas !? ça fait vraiment rien tout seul en fait, on est obliger d'avoir php/asp ou autres avec

mais mysql peut avoir l'attribute "auto_increment" sur un champ, qui est qd meme l'application la + courante des triggers, en BCP + facile/simple

Petite contribution :
MySQL est l'un des SGBD les plus rapides qu'il existe. Ce choix s'est fait par les concepteurs dès sa conception et s'explique en partie par l'abandon de certaines fonctionnalités du langage SQL et particulièrement la logique transactionnelle et les triggers (et les vues, et les procédures stockées et les clés étrangères...). PostgreSQL a lui choisi de suivre au mieux les spécifications SQL et est donc plus complet mais moins rapide. Donc voilà, même les éditeurs de MySQL le disent, si c la rapidité qui est recherché : MySQL, si par contre il y a un besoin de transactions, de vues,... : PostgreSQL. Tout dépend de l'utilisation et du besoin. Z0rglub : Si on trouve peu d'hébergeurs SQL sous PostgreSQL c'est qu'à ce niveau là MySQL est bien plus performant. Enfin on trouve des dizaines de comparaison sur Internet, donc une petite recherche Google devrait permettre de se faire une idée.
(pour infos, les Select imbriqués et les clés étrangères arrioveront dans la version 4.1 de MySQL, le reste un peu plus tard )
 
Voilà !

salut Poulou
merci de ton apport d'informations... j'espère que les hébergeurs accepeterons de proposer au choix des serveurs MySQL 3.x et 4.x, pour que ceux qui ont besoin de performances mais des requêtes simples puissent prendre le 3.x et ceux qui ont des requêtes complexes puissent utiliser 4.x... On verra.
Je dois dire que je me suis habitué à contourner le pb des selects imbriqués et à faire gérer par l'application les clés étrangères, mais bon, c'est pas toujours optimal...

l'un est une vrai SGBD "professionnel" l'autre est un pseudo SGBD "juste bon pour les amateurs" ...

c'est QUOI ce vieux up déguisé en troll!!!  

pour les bases de données gratos on a fait un topic plus bas  
http://forum.hardware.fr/forum2.ph [...] subcat=395
 
mais si tu veux un serveur sur internet c'est vrai q'uil ya que myslq sinon faut bien chercher

Raaaaa mais les conneries de racontées sur mysql !!
 
MySQL gère les foreigns Key et MySQL est transactionnel (+ row locking) pour peut qu'on utilise le handler innodb (qui est compilé par défaut avec les dernières version de MySQL).
Donc t'as le choix entre le handler MyISAM non transactionnel, qui ne gère pas les foreigns key et qui marche sur du table locking, et innodb (voir bdb ou gemini, qui sont moins utilisés).
 
Les subselects et les vues devraient par contre arrivés dans la 4.1 qui est d'ores et déjà en cours de dev.

en fait PostgreSQL est pratiquement le clone d'oracle vraiment tres tres complet, foreignkeys, selections imbriquee (comme dans oracle), triggers, sequences, etc...
Oui il est tout indique pour un usage pro.
 
Mysql est bien mais pas (enfin pas encore cd projet des nouvelles versions) aussi proche d'oracle que PostgreSQL.
 
En clair si c'est pour un serveur WEB !!ATTENTION seuls les hebergeurs 100% Unix/linux/bsd le gerent !!
les autres sont au moins en partie sous kro$oft.
et la Mysql est mieux indique.
 
Pour tout autre usage ou en intranet la POSTGRESQL sans esitation (tres facile a installer/configurer sous unix,linux,bsd).
 
il parrait qu'il peut aussi marcher sous NT mais bon c'est pas fait pour et ca se ressent dans le merdoyage pour l'y installer.
 
 
 

 
oui en ce qui concerne postgre ss kro$oft c'est chiant à installer disons quand on a pas l'habitude moi je l'ia installer et je suis entraine defaire les tests de rapidité à faire à suivre ....

 
 
sous microsoft c'est selon les machine a peine + lent voire tout aussi rapide que sous unix.
 
mais bon mois je suis que sous unix, linux, et autres BSD  donc...je peux pas t'en dire plus.

L'un est un SGBD, l'autre est un système de fichier avec une syntaxe d'access SQL qui se prend pour un SGBD
 
Avec tous les cours que j'ai eu sur ce sujet, ca me fait mal de voir des gens appeller MySQL un SGBD.

Kristoph a écrit a écrit : L'un est un SGBD, l'autre est un système de fichier avec une syntaxe d'access SQL qui se prend pour un SGBD   Avec tous les cours que j'ai eu sur ce sujet, ca me fait mal de voir des gens appeller MySQL un SGBD.

ca c'est parce que tu connais pas le handler innodb...
je crois pas qu'avec un système de fichier avec syntaxe d'access SQL tu puisses faire tu row locking, gérer les lignes fantomes, faire du transactionnel, etc.

C'est juste une petite évolution. Ca veux dire que les choses vont dans la bonne direction pour MySQL. Mais c'est pas encore suffisant.
 
Question : Est-ce que MySQL sera toujours aussi rapide quand il aura les mêmes capacités que PostGreSQL ?

une "petite" évolution ??
Elle est majeur oui Ca veut dire que MySQL gère les foreigns keys, est transactionel, et plusieurs autres avantages. Et avec le handler innodb MySQL reste très très rapide. Les subselects sont normalement prévus en fin d'année, en stade alpha (branche 4.1).
Et si t'en as rien à battre du row locking et des transactions, hop tu crées une table au format MyISAM et t'as des perfs maximales. (le forum utilise à la fois du MyISAM et du InnoDB par exemple)

Qu'est-ce qu'il fait là ce topic qui date de + de 3 mois !... Forcément depuis, j'ai eu le temps d'apprendre des choses, particulièrement InnoDB !
D'ailleurs puisqu'on y est, le handler par défaut dans la v4, ça restera MyISAM ou il passe à du InnoDB ? En tt cas, ils le mettent vraiment en avant contrairent à du BerkeleyDB qui n'a pas eu une pub terrible alors qu'il a été le premier à pouvoir gérer les transactions sous MySQL. Le fait que InnoDB soit également d'un pays scandinave (finlandais et suédois/finlandais pour MySQL) ne doit pas y être étranger !

ca reste MyISAM par defaut
Sinon heikki de InnoDB travaille main dans la main avec MySQL et commit dans le repository MySQL, ce qui etait pas le cas de BDB qui etait vraiment a part.