Articles précédents : Logiciel
Liens connexes
- Annonce MySQL (582 hits)
- Critique de MySQL par IBM et Microsoft (1391 hits)
- MySQL (348 hits)
- InnoDB (346 hits)
Dépêche modérée par
Logiciel : MySQL: une bonne et une mauvaise nouvelle.
Posté par matiasf (). Modéré le 25 septembre 2002.
MySQL supporte les transactions ACID (Atomicité, Cohérence, Isolation, Durabilité), les contraintes d'intégrités référencielles et les sauvegardes à chaud grace à l'utilisation du moteur de stockage InnoDB.
La mauvaise :
IBM et Microsoft critiquent MySQL.
![[en]](../../../images/en.png)
Annonce MySQL (582 hits)-
Critique de MySQL par IBM et Microsoft (1391 hits)
-
MySQL (348 hits)
-
InnoDB (346 hits)
> Lire les commentaires (73 commentaires, moyenne: 5,9).
ce sont deux bonnes nouvelles.
IBM et Microsoft critique MySQL c'est aussi une bonne nouvelle et d'ailleurs c'est surtout une bonne nouvelle pour MySQL Inc. ils font peur à Ms et IBM.
-
[^]Re: ce sont deux bonnes nouvelles.
Posté par Obsidian () le 25/09/2002 à 13:02. (lien). Évalué à 19.Petite correction:
IBM et Microsoft critique MySQL.
s/critique/critiquent/
Sinon, ce n'est pas une si mauvaise nouvelle. Les « faiblesses » de MySQL sont reconnues par l'équipe de développement elle-même (pas de commit/rollback, par exemple, si je ne me trompe pas), et il s'agit la plupart du temps de choix délibérés pour privilégier la vitesse d'exécution.
Il est très probable que MySQL ne tienne pas en charge, il reste quand même mon serveur de base de données domestique préféré, et est largement suffisant pour la plupart des petits serveurs web.
Cela devrait être une bonne nouvelle pour tout le monde: Les « poids lourds » des serveurs de BDD s'adressent à un public complètement différent, et personne ne se fait de l'ombre (vous imaginez DB2 en tâche de fond sur le PII/64Mo du salon ?).
Non, le vrai problème à mon avis vient probablement du fait que ces fameux poids-lourds ne tiennent pas toujours leur promesses: Ici au travail, on utilise Sybase et on connait certains problèmes de génération automatique d'ID de clé primaire lorsque le serveur est fortement sollicité, ce qui compromet la cohérence de la base. Montrer du doigt MySQL sert peut-être à détourner l'attention des utilisateurs loin des défauts des autres serveurs.
En ce qui concerne Microsoft, il semble que ce soit le coté Open Source de la chose qui les effraie: « Avec l'open-source, vous n'obtiendrez pas une plateforme aussi fiable, évolutive ou sécurisée qu'avec un fabricant leader sur le marché ». Toujours le même FUD, quoi, sauf qu'il ne prennent même plus la peine d'argumenter ! :-) De toute façon, le travail de sape envers le libre d'un coté et l'Open Source en général n'est même plus dissimulé à Redmond: Jusqu'à présent, ils avaient pour habitude de racheter les produits qui risquaient de leur faire concurrence, ce qui devient impossible avec le libre, et s'ils trainent souvent les pieds pour ouvrir leur sources, c'est bien parce qu'ils ne sont probablement pas présentables. Enfin, s'ils clament haut et fort que l'Open Source est un danger pour la sécurité des logiciels, c'est qu'ils parlent probablement pour eux :-)
Dans tout cela, MySQL semble s'en sortir blanc comme neige ...
Pour finir, pour tout ceux que le SQL et les BDD gonflent (courant chez les programmeurs) mais qui sont quand même obligés de s'y coller, je recommande ce site:
http://sqlpro.developpez.com(...)
Le tutoriel est pas mauvais du tout, il y a des comparatifs des différents bouquins, et surtout des exemples de plein de cas de figure en SQL, standards ou non, avec l'état de leur implémentation dans les différents SGBD, dont MySQL (le tableau est en bas de page pour chaque chapitre).
Bon travail à tous ...-
[^]Re: ce sont deux bonnes nouvelles.
Posté par Olivier Jeannet () le 25/09/2002 à 14:42. (lien). Évalué à 16.Il est très probable que MySQL ne tienne pas en charge
Regarde le comparatif fait entre 4 bases de données commerciales et MySQL, MySQL est au top avec Oracle et sur un gros truc (serveur quadri-Xeon, 2 Go mémoire, disques SCSI Ultra3, sous Windows 2000) qui tourne pendant 8 heures :
http://www.eweek.com/article2/0,3959,293,00.asp(...)
(j'ai honteusement pompé l'URL donnée par Xavier Poinsard à 11h57, qu'il soit remercié (et "scoré" [+] :-) )
-
[^]Champion du monde
Posté par Moby-Dik () le 25/09/2002 à 18:32. (lien). Évalué à 4.(pas de commit/rollback, par exemple, si je ne me trompe pas)
Extraordinaire ! Ca t'arrive de lire la news du dessus, avant de dire des conneries ?
Là je suis scié... ;)
Il est très probable que MySQL ne tienne pas en charge
Génial ton troll :-)) Il est très probable que tu sois rigoureusement incompétent pour faire preuve d'une argumentation aussi foudroyante, non ?
-
[^]Re: ce sont deux bonnes nouvelles.
Posté par Flyounet (page perso, ) le 26/09/2002 à 09:31. (lien). Évalué à 1.Il est très probable que MySQL ne tienne pas en charge
He ho, il a quand même permis à iBazar de tenir en attendant le portage dous Oracle !
Bon OK, la base était reconstruite toutes les nuits, mais bon ...
Et pis l'affiliation avec ses millions d'enregistrements et de select/insert/update/delete a été très contente de la sortie de la 3.23.*
Donc MySQL tient la charge... si on l'aide un peu...
N.B. : Attention un troll risque de se cacher dans la phrase suivante : "Oracle c'est trop cher pour ce que ça fait"-
[^]Re: ce sont deux bonnes nouvelles.
Posté par Olivier Jeannet () le 26/09/2002 à 10:03. (lien). Évalué à 2.He ho, il a quand même permis à iBazar de tenir en attendant le portage dous Oracle ! Bon OK, la base était reconstruite toutes les nuits, mais bon ... Ca m'intéresse d'en savoir plus sur l'utilisation de MySQL par IBazar, tu peux en dire plus ? (j'avais lu il y a 2 ans une interview d'un responsable de IBazar qui parlait de MySQL) Et pis l'affiliation avec ses millions d'enregistrements et de select/insert/update/delete a été très contente de la sortie de la 3.23.* C'est à dire ? (je ne suis pas un pro de MySQL)
-
[^]Re: ce sont deux bonnes nouvelles.
Posté par Moby-Dik () le 26/09/2002 à 10:23. (lien). Évalué à 1.C'est à dire ? (je ne suis pas un pro de MySQL) En fait la version 3.23 (qui existe depuis un bout de temps déjà) a introduit la possibilité de faire des SELECT en parallèle avec des INSERT, ce qui résoud partiellement un gros problème de MySQL : le verrouillage se fait au niveau table, donc une grosse requête en écriture peut bloquer une requête en lecture sur des lignes différentes, et vice-versa.
-
[^]Re: ce sont deux bonnes nouvelles.
Posté par Olivier Jeannet () le 26/09/2002 à 23:45. (lien). Évalué à 1.Et le coup de la reconstruction toutes les nuits, c'était quoi ? Tu peux en dire plus stp ? (je veux tout savoir sur l'utilisation que IBazar en faisait ;-) Tu as bossé pour eux à l'époque ?
-
-
-
-
Mauvaise nouvelle : les éditeur de base de données ont peur :)
Sans déconner, IBM c'est DB2 et Microsoft c'est MachinQL (J'ai plus le nom en tête).
Quand je vois des petites boites utilisées se genre de base de données pour le peu de truc mis dedans et le peu d'accès, je me dis que MySQL ou posgresql serait largement suffisant.
Et puis quand on voit l'utilisation massive de MySQL pour le web on peut difficilement dire que c'est nul
-
[^]Re: Mauvaise nouvelle : les éditeur de base de données ont peur :)
Posté par Benjamin () le 25/09/2002 à 09:56. (lien). Évalué à 22.Bah tu sais.. déjà que les technologies libres ne sont pas utilisées quand elles sont bien meilleures , c'est pas pour les utiliser quand elles sont "seulement" mieux adaptées..
Et puis, quoi de plus rassurant que de payer un gros chèque ?
-
[^]Re: Humm
Posté par zeDek () le 25/09/2002 à 10:06. (lien). Évalué à 34.Et puis quand on voit l'utilisation massive de MySQL pour le web on peut difficilement dire que c'est nul
Contre-exemple : 80 à 90% des plateformes (de bureau) tourne un zindows. Et je suis que tu ne diras jamais que zindows c'est Bien(tm).
Donc ton argumentaire n'est AMA pas valable. C'est pas parce que un truc est vachement utilisé que c'est forcément Bien(tm). L'inverse n'est pas vrai non plus.
Y a plein d'exemples qui marchent bien avec ce que je viens de dire : IE, etc...-
[^]Re: Humm
Posté par Infernal Quack (Jabber id, page perso, ) le 25/09/2002 à 10:12. (lien). Évalué à 19.MySQL est vachement utilisé (Elle a pas le monopole mais quand même) et elle a fait ses preuves. Tu as raison de préciser que ma phrase portait à confusion et aussi de dire que je ne dirais jamais que windows c'est bien ;)
Alors maintenant que les transactions sont gérées, ça devrait être de mieux en mieux.-
[^]Re: Humm
Posté par zeDek () le 25/09/2002 à 10:19. (lien). Évalué à 12.Heureux de te l'entendre dire :)
Concernant les transactions, c'est vrai que c'était un des gros manques de MySQL pour être considéré comme une vrai DB (pour pros j'entends).
Enfin l'oubli est réparé maintenant. Je vais enfin pouvoir essayer de le (MySQL) faire entrer dans ma boîte. C cool !! :)-
[^]Re: Humm
Posté par matiasf () le 25/09/2002 à 10:24. (lien). Évalué à 15.Regarde PostgreSQL si tu n'es pas familiarisé avec MySQL. PostgreSQL est plus puissant que MySQL (trigger, fonctions embarqué, types utilisateurs, view, etc...).
Et tu peux utiliser PostgreSQL comme tu utilise MySQL.
Mais PostgreSQL a des points faibles par rapport à MySQL. Le plus gros problème, est qu'il ne tourne pas sous Windows :-) ...-
[^]Re: Humm
Posté par zeDek () le 25/09/2002 à 10:33. (lien). Évalué à 18.C'est ce que j'utilise actuellement pour mes serveurs. Et c'est vrai que niveau features à l'époque où j'ai choisi de prendre postgres, ben y avait pas photo.
Maintenant moi je n'ai pas de gros besoin en ce qui concerne une base de donnée. Mes bases me servent pour les logs, le DNS, le serveur de mail, etc...
Bref que des petits trucs quoi donc
Mais PostgreSQL a des points faibles par rapport à MySQL. Le plus gros problème, est qu'il ne tourne pas sous Windows :-) ...
Je pense que le smiley est de trop ici. Postgres devrait être plus connu qu'il ne l'est actuellement (AMA). Et c'est dommage qu'un port vers win ne soit pas encore fait car la renommée de MySQL n'est plus à faire et il est aussi bien connu dans l'Underground (nunux & co) que dans le grand public (zindows). La preuve en est faite aujourdh'ui : MS les critique :)
Je pense que PostgresSQL n'est pas reconnu à sa juste valeure et c'est dommage car comme tu le dis toi même c'est une excellente alternative à MySQL.-
[^]Re: Humm
Posté par zeiram () le 25/09/2002 à 10:51. (lien). Évalué à 15.PostgreSQL est disponible pour Windows. Peut-être pas sous la forme d'un port réellement natif (je ne sais pas, je n'ai pas vérifié) mais en tout cas il existe sous forme de package pour Cygwin.
Zeiram
-
[^]Re: Humm
Posté par gnap gnap (page perso, ) le 26/09/2002 à 11:57. (lien). Évalué à 1.Mais Windows n'est pas conçu pour être un serveur... Donc là n'est pas l'essentiel...
-
[^]Re: Humm
Posté par grmbl (page perso, ) le 26/09/2002 à 14:46. (lien). Évalué à 1.C'est dispo mais inexploitable : lourdingue et plantouilleux. J'ai dû l'abandonner sur un projet wxpython+postgresql qui devait servir d'intermédiaire avant un passage à du tout-linux. C'est dommage parceque nombre de programmeurs indépendants auraient tout à gagner avec ce couple !
-
-
-
[^]Re: Humm
Posté par David Douard () le 25/09/2002 à 11:59. (lien). Évalué à 8.A ce propos (MySQL/PostgreSQL), j'ai très souvent entendu des gens dire, en substance :
"PostgreSQL, ouais, mais niveaux perfs, c'est pas ça !".
Quelqu'un (qui connait bien les BD) a-t'il un avis éclairé sur la question ?
C'est à dire : existe-t-il des comparatifs de ces 2 BD, les 2 étant parfaitement "tunées" (je sais Postrgre y être très sensible) ? Un truc sérieux, je veux dire.
Merci-
[^]Re: Humm
Posté par zeDek () le 25/09/2002 à 12:06. (lien). Évalué à 8.Un lien (attention espagnol inside) contenant plein de liens interessans sur le sujet :
http://www.mmlabx.ua.es/mysql-postgres.html(...)
et voici un lien sur une news parue sur /. (ca date un peu mais bon):
http://slashdot.org/articles/00/08/14/2128237.shtml(...)
Enifn un dernier :
http://www.mysql.com/information/benchmarks.html(...)
Voila
-
[^]Re: Humm
Posté par matiasf () le 25/09/2002 à 12:50. (lien). Évalué à 13.çà peut déraper en troll.
PostgreSQL, s'il est utilisé comme MySQL ne sera pas plus rapide que MySQL (sauf sous certain cas de forte charge (beaucoup de connections en parallèle)).
Si tu utilises les fonctionnalités de PostgreSQL (trigger, etc...) PostgreSQL sera probablement plus lent que MySQL. Mais comme il fait plus de boulot on ne peut pas conclure qu'il est plus réellement plus lent (le travail fait par PostgreSQL est généralement fait avec des scripts php lorsque tu utilises Mysql).
Il est souvent écrit que PostgreSQL est plus lent que MySQL en écriture. C'est uniquement un problème de configuratation. Par défaut PostgreSQL, pour des raisons d'intégrité de donnée, fait un flush() à chaque transaction. Mysql n'est pas toujour configurer pour faire ce flush(). Si les deux SGBDR ont la même config, les perfs sont très proche.
Bref, niveau perfo c'est la même chose. Par contre, PostgreSQL peut bouffer plus de mémoire (c'est aussi fonction de la configuration).-
[^]Re: Humm
Posté par Moby-Dik () le 25/09/2002 à 18:35. (lien). Évalué à 0.
çà peut déraper en troll.
C'est déjà fait.
Si les deux SGBDR ont la même config, les perfs sont très proche.
Ah bon ? Allez, hop, des chiffres pour changer des trolls débiles :
http://www.innodb.com/bench.html(...)-
[^]Re: Humm
Posté par matiasf () le 25/09/2002 à 19:58. (lien). Évalué à 2.Super, vla l'ouverture d'un concours de troll...
Il est claire qu'il est supprenant que le site innodb dise du bien d'innodb !
Je crois en leur honnêté car il ont du bosser très dure. Pas facile de trouver deux cas où PostgreSQL est plus lent qu'innodb.
Bon, c'est pas tout çà mais ... tu m'inspires.
J'ai dans l'idée de faire un tour sur http://www.microsoft.com/(...) pour éclairer votre lanterne et démontrer à quel point GNU/Linux est une merde.
En toute impartialité évidemment.-
[+] [^]Re: Humm
Posté par Moby-Dik () le 25/09/2002 à 20:35. (lien). Évalué à -2.J'ai dans l'idée que tu ne comprends pas la différence entre des arguments vides de contenu ("je suis sûr que c'est de la merde") et des chiffres. Après, si tu contestes les chiffres d'innodb, rien ne t'empêche de poster les tiens après tout.
-
[^]Re: Humm
Posté par matiasf () le 25/09/2002 à 20:55. (lien). Évalué à 2.C'était de l'humour. Caustique certe, mais de l'humour (tu as toi même indiqué que l'on était dans le troll).
Les benchs, c'est le cadet de mes soucis. 20 % de performance en plus, c'est 3/4 mois d'évolution de hardware.
Mais puisqu'il faut être sérieux, j'ai une URL fournie par la FAQ de postgresql ( http://www.ca.postgresql.org/docs/faq-english.html(...) ) que j'ai pas envie de cautionner :
http://openacs.org/why-not-mysql.html(...)
-
-
-
-
[^]Encore des chiffres
Posté par Moby-Dik () le 25/09/2002 à 20:52. (lien). Évalué à 1.Cette fois-ci, ils sont donnés sur la liste des développeurs PostgreSQL :
http://archives.postgresql.org/pgsql-hackers/2002-09/msg01270.php(...)
Mais bon, ils sont eux aussi à l'avantage de MySQL. Même en désactivant fsync sous Postgres, le gars à son grand regret ne constate pas de différence : MySQL est toujours cinq fois plus rapide en insertions.
-
-
[^]Re: Humm
Posté par Olivier Jeannet () le 25/09/2002 à 14:52. (lien). Évalué à 4.j'ai très souvent entendu des gens dire, en substance :
"PostgreSQL, ouais, mais niveaux perfs, c'est pas ça !".
Des tests conduits il y a longtemps (été 2000) montraient que PostgreSQL était plus lent mais qu'il tenait mieux la charge (3x plus de connexions), et qu'en fin de compte il délivrait autant de transactions par seconde. MySQL avait protesté en disant que le test montrait la force de PostgreSQL et pas ses faiblesses (je crois que quelqu'un a donné des liens là-dessus).
Depuis les 2 ont bien évolué et ça serait intéressant à faire. De toutes façons PostgreSQL est nettement plus riche en fonctionnalités (triggers, subselects, norme SQL 93, procédure stockées en plusieurs langages, etc).
-
[^]Re: Humm
Posté par Gloo () le 25/09/2002 à 20:53. (lien). Évalué à 8.C'est comme si tu comparais un parseur de fichier binaire que tu aurais écrit toi même en C en une après midi d'une part, et oracle d'autre part. Ton parseur irait plus vite, c'est certain. Par ailleurs tunner ton appli C ce n'est pas la même chose que tunner un Oracle. Idem pour MySQL et PostgreSQL.
Ca fait DES ANNEES que PostgreSQL possède tout ce dont parle la news et bien plus comme, les procédures stockées, les foreign keys, les views, ou les triggers, et surtout, une documentation et un code propre et comprehensible. PostgreSQL remplace dejà des Oracles ou autre pour des applications critiques dans des boites (Auchan dernièrement en France) avec des miliers d'utilisateurs. Des responsables y ont fait leur boulot, c'est a dire prendre des responsabilités.
Alors oui, c'est chouette, MySQL est sur le point d'entrer dans la cours des grands ( dans quelques années ) et ca permettra à une horde de developpeurs de seconde zone d'enfin (!) s'appercevoir que gerer des transactions au niveau applicatif, ca revient à ne pas les gerer du tout. Bref, d'avoir enfin des applications en beton, c'est à dire utilisables en dehors du cadre web non-critique.
Dommage que ce soit MySQL qui vienne lentement au developpeur et pas les developpeurs qui soient allés vers PostgreSQL qui possède toujours une très longue avance sur MySQL: des années d'experience et de production. Cela aurait d'offrir des applications dignent de confiance depuis DES ANNEES.
Après cette "annonce" (je suis trop habitué au vaporware mysqlien) je vais me replonger dans un comparatif fonctionnel des deux bases de données. Malheureusement cela prend du temps: la doc de MySQL melangeant allègrement ce que fait/fera la stable/beta/alpha.
Au fait, devinez laquelle des deux bases se conforme le mieux au standard ANSI SQL...
Ce que pense IBM qui vend DB2 et qui marche sous linux, ou Microsoft avec son SQLServer abonné à BugTraq, je m'en fiche un peu. Il suffit de consulter les mailing lists et group de news pour se rendre compte que les migrations vers PostgreSQL ne sont pas rares mais que PostgreSQL et trop meconnu. Imaginez que MySQL arrive au niveau de postgreSQL avec sa notoriété. Oui, les IBM et Microsoft ont de quoi se faire du souci.-
[^]Re: Humm
Posté par Moby-Dik () le 25/09/2002 à 21:01. (lien). Évalué à 2.PostgreSQL qui possède toujours une très longue avance sur MySQL: des années d'experience et de production.
C'est d'autant plus idiot comme affirmation qu'avant la version 7, Postgres était rigoureusement inutilisé en production à cause de problèmes chroniques de bugs et de stabilité.
Malheureusement cela prend du temps: la doc de MySQL melangeant allègrement ce que fait/fera la stable/beta/alpha.
??? Absolument n'importe quoi. Je te conseille de relire calmement la doc en question au lieu de troller comme un malade. D'ailleurs comme la news parle spécifiquement du type de tables innodb, tu auras aussi vite fait de consulter la doc innodb, qui est très claire.
Des responsables y ont fait leur boulot, c'est a dire prendre des responsabilités.
Ah ouais, c'est les forces vives des marmottes qui gagnent dans le papier alu, quoi :-)))-
[^]Re: retourne jouer aux billes.
Posté par Gloo () le 25/09/2002 à 21:36. (lien). Évalué à 0.http://developer.postgresql.org/docs/postgres/history.html(...)
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/HISTORY(...)
http://www.linuxworld.com/linuxworld/lw-1999-07/lw-07-finalists.htm(...)
july 99... mmm vers la 6.5... Derrière Oracle.
http://www.pgsql.com/user_gallery/stats.php(...) (Summaries by Postgresql Version)
"avant la version 7, Postgres était rigoureusement inutilisé"
Excuse moi, tu peux me rappeler où est le troll dejà ?
Elle était justement très peu utilisée à cause de rigolo comme toi, completement incompetent sur le sujet et qui se permettent de l'ouvrir.-
[^]Re: retourne jouer aux billes.
Posté par matiasf () le 25/09/2002 à 21:49. (lien). Évalué à 1."Summaries by Postgresql Version" qui marche :
http://www.pgsql.com/user_gallery/stats.php?field=postgresql_versio(...)
-
[^]Re: retourne jouer aux billes.
Posté par Moby-Dik () le 25/09/2002 à 22:04. (lien). Évalué à 0.www.linuxworld.com/linuxworld/lw-1999-07
On y voit en effet Postgres nominé en 99. Gnome est aussi nominé dans sa catégorie. Gnome était peut-être mûr en 99, tu crois ? On se fiche un peu de savoir si Postgres a gagné des prix (et quand pour le prix en question, qui récompense les "avancées du mouvement open source", on nomine Oracle, ça fait un peu ridicule...).
developer.postgresql.org/docs/postgres/h
developer.postgresql.org/cvsweb.cgi/pgsq
Super, un historique de Postgres. Les développeurs de Postgres utilisent Postgres ? Qu'est-ce que ça me prouve ? Tiens, pour info, ça fait des années que les développeurs de MySQL utilisent MySQL. Dingue non ?
Enfin si tu étais un bon défenseur, et donc un bon connaisseur de Postgres, tu saurais que pour avoir une utilisation efficace en lançant périodiquement un vacuum() sur la base, tu étais obligé de débrancher la base pendant le vacuum avant les version 7.x. Et le dit vacuum peut prendre beaucoup beaucoup de temps. C'est un problème très connu.
Côté stabilité, les versions antérieures à la 7.0 étaient de plus réputées (y compris encore une fois du côté des pro-postgres) contenir beaucoup de bugs, problèmes de stabilité et autres crashes. Ce qui est problématique pour une utilisation "en production", surtout si la dite production ne suppporte pas d'être arrêtée, vacuumisée puis relancée toutes les nuits. Le fait que Linux Chose Magazine file un prix à Postgres n'y change rien (mais le singe aime la voiture rouge qui gagne des prix).
Elle était justement très peu utilisée à cause de rigolo comme toi, completement incompetent sur le sujet et qui se permettent de l'ouvrir.
Ah ok ! :-))
www.pgsql.com/user_gallery/stats.php
J'y peux rien mais ça me renvoie ça :
Warning: pg_exec() query failed: ERROR: parser: parse error at or near "," in /usr/local/www/pgsql.com/www/user_gallery/stats.php on line 16
Warning: pg_numrows(): supplied argument is not a valid PostgreSQL result resource in /usr/local/www/pgsql.com/www/user_gallery/stats.php on line 17
Warning: pg_exec() query failed: ERROR: Function 'count()' does not exist Unable to identify a function that satisfies the given argument types You may need to add explicit typecasts in /usr/local/www/pgsql.com/www/user_gallery/stats.php on line 20
Warning: pg_numrows(): supplied argument is not a valid PostgreSQL result resource in /usr/local/www/pgsql.com/www/user_gallery/stats.php on line 21
Il y a des entreprises de Redmond qui se font descendre pour moins que ça ;-)) Mais ça doit être parce que je suis un rigolo incompétent (sic).-
[^]Re: retourne jouer aux billes.
Posté par Gloo () le 25/09/2002 à 23:46. (lien). Évalué à 0.Je te donne des dates, le HISTORY pour que tu fasses tes associations et que tu te rendes compte que dire que "avant la version 7, Postgres était rigoureusement inutilisé en production" est un absurdité totale ou un FUD. "DES ANNEES", si ca te travaille vraiment, ca peut dire aussi 2 ans: c'est la version 7. En fait, je pense surtout aux versions 6.5.x (99)
Maintenant, si tu ne veux pas lire, tes effets de style ne convaincront que toi.
Par ailleurs je n'ai pas dit que postgreSQL était exempte de problème. Le vacuum est un mauvais exemple. Avec un design correct avec DES bases (enormes style http//www.geocrawler.org/ qui tournait bien avant la version 7) ce n'est pas un vrai problème. Par ailleurs, vois-tu, c'etait le moment de faire les backups.
(je ne sais pas aujourd'hui quelle version de postsgres utilise geocrawler et s'ils ont toujours une rupture de service à ce propos.)
Bref, Pour faire un vrai backup ajourd'hui sous mysql faut arreter la base.
* mysqlhotcopy utilise LOCK TABLES
* perldoc mysqlhotcopy:
"WARNING: THIS PROGRAM IS STILL IN BETA. Comments/patches welcome."
* http://www.mysql.com/doc/L/O/LOCK_TABLES.html(...)
"3. Lock one table at a time until the thread gets all locks." super pour la consistence...
Aujourd'hui pour postgresql:
"pg_dump makes consistent backups even if the database is being used concurrently. pg_dump does not block other users accessing the database (readers or writers)."
"y compris encore une fois du côté des pro-postgres) contenir beaucoup de bugs, problèmes de stabilité et autres crashes."
Moi j'argumente, toi tu FUD.
"[problème du lien]"
oui, que veux tu, il y en a qui ne sont pas doués pour faire des SGBDR (Mysql), d'autres pour faire des sites avec php (PostgreSQL).
http://www.pgsql.com/user_gallery/stats.php?field=postgresql_versio(...)
Ca le fera mieux.-
[^]backup
Posté par Moby-Dik () le 26/09/2002 à 10:10. (lien). Évalué à 0.Bref, Pour faire un vrai backup ajourd'hui sous mysql faut arreter la base. Non, faux. Tu utilises une couche filesystem permettant les snapshots (type LVM ou Veritas), et il te suffit d'exécuter FLUSH TABLES WITH READ LOCK juste avant le snapshot. Ensuite, tu UNLOCK TABLES et c'est fini. Et tu es bon pour backuper tranquille le snapshot pendant que la base continue à tourner.
-
[^]Re: backup
Posté par matiasf () le 26/09/2002 à 11:45. (lien). Évalué à 3.Si tu as des relations entre table, il faut vérouiller toutes les tables et durant tout le backup (qui peut-être long pour une grosse base) tu ne peux pas écrire dans la base de donnée. PostgreSQL (si tu as bien défini les contraintes, etc...) tu permet de faire un backup cohérent de toutes les tables à la fois et la base de donnée reste disponible en lecture et écriture. çà c'est un vrai backup à chaud.
-
[^]Re: backup
Posté par Moby-Dik () le 26/09/2002 à 11:56. (lien). Évalué à 0.STP, relis ce que j'ai dit. J'ai dit que tu verrouillais les tables pendant le *snapshot*. Créer un snapshot sous LVM dure une seconde (le snapshot est initié sur un logical volume séparé). Donc le verrouillage ne dure qu'une seconde. Le backup a lieu ensuite sur le snapshot et non sur le filesystem "live". (note : LVM est intégré au noyau Linux, il faut juste l'activer à la compil)
-
-
[^]Re: backup
Posté par Gloo () le 26/09/2002 à 16:51. (lien). Évalué à 2."FLUSH TABLES WITH READ LOCK juste avant le snapshot [...] Ensuite, tu UNLOCK TABLES" et [...] ... ca marche pas... bien. Je te donnes des pistes: - snapshot pas instantané - cache lvm, cache OS, cache hardware - locks pas fait de façon atomique (cf plus haut) - y a des UNDO et REDO chez mysql maintenant ? - ... Enfin, l'idée c'est quand même d'avoir après la restauration des données coherentes, pas uniquement une base qui demarre peut être. Tu ne te demandes pas pourquoi oracle, postgresql ou mysql n'abordent pas (toujours) les snapshots (lvm, netapp...) dans leur doc, et developpe tous des outils plus ou moins compliqués ? Bref, pour des appli web-non-critique ou il n'y a pas trop d'ecriture il y a des chances que ca marche plutôt bien... Pour le reste je n'arrive plus a mettre la main sur un long troll qui parle de precisement de ca.
-
[^]Re: backup
Posté par Moby-Dik () le 26/09/2002 à 18:37. (lien). Évalué à 1.Je te donnes des pistes: - snapshot pas instantané - cache lvm, cache OS, cache hardware - locks pas fait de façon atomique (cf plus haut) - y a des UNDO et REDO chez mysql maintenant ? - ... - snapshot = temps de création du logical volume à l'intérieur du volume group = une seconde - LVM est intégré au noyau et fait un flush du filesystem (y compris le journal ext3) juste avant la création du logical volume => aucun problème de cohérence - cache hardware : rien à voir, car LVM travaille au niveau noyau et opère en mode copy-on-write, c'est-à-dire que tout bloc modifié après la création du snapshot est recopié dans sa version originale avant d'être écrit sur le disque. D'autre part, je te signale que dans le cas d'un SGBD il vaut mieux utiliser du hard qui obéit aux requêtes de synchronisation, donc probablement du SCSI. Sinon ton système n'est plus ACID. - UNDO et REDO : je ne vois pas le rapport, on parle de backups là. Si tu veux restaurer un backup sous MySQL, c'est tout simple, tu arrêtes le serveur, tu remets les fichiers à leur place et hop. c'est quand même d'avoir après la restauration des données coherentes Cohérentes vis-à-vis de quoi. Je te répondrais bien de RTFM, mais répétons encore un coup : - FLUSH TABLES WITH READ LOCK assure la cohérence des données au niveau SGBD. Cela garantit que la représentation des tables sur le filesystem est stable et cohérente (y compris au sens ACID du terme si tu utilises InnoDB (lis la news...)). - la prise du snapshot sous LVM assure de plus la cohérence des données au niveau filesystem. En effet LVM est intégré au noyau et a donc une connaissance totale des blocs flushés ou non. Il installe donc une barrière à un certain moment, flushe tout ce qui n'a pas été flushé et bloque toute modif arrivante, crée le logical volume, puis redonne la main. - par la suite, la permanence du snapshot est assurée par un mécanisme de copy-on-write, toujours grâce au fait que LVM est intégré directement au noyau. - le backup est fait à partir du snapshot, qui est stable et permanent (cf. ci-dessus). Une fois le backup fini, tu détruis le snapshot histoire de ne pas subir la perte (très minime) de performances. Donc la cohérence est garantie (sauf bug bien sûr ;-)) sur toute la chaîne. pourquoi oracle, postgresql ou mysql n'abordent pas (toujours) les snapshots (lvm, netapp...) dans leur doc, et developpe tous des outils plus ou moins compliqués ? Parce que les snapshots ne sont pas une fonctionnalité de base des filesystems (je ne pense pas qu'il y en ait sous Windows, sous linux les distribs n'utilisent pas LVM par défaut, etc.). Et aussi parce qu'une des caractéristiques de beaucoup de bases de données (surtout commerciales) est d'intégrer le plus d'outils pour créer de la valeur ajoutée (tm ;-)) ou faire plaisir à l'utilisateur (tout est out-of-the-box).
-
[^]Re: backup
Posté par Gloo () le 26/09/2002 à 19:31. (lien). Évalué à 1."intégrer le plus d'outils pour créer de la valeur ajoutée" tu parles de ca ? "MySQL costs $395 per server" http://www.infoworld.com/articles/hn/xml/02/09/20/020920hnmysql.xml ou encore de ca ? "InnoDB Hot Backup [...] 1-year licenses (400 euros or 400 US dollars each)" http://www.innodb.com/hotbackup.html "UNDO et REDO : je ne vois pas le rapport, on parle de backups là." Je ne parle pas de COMMIT et de ROLLBACK et bien d'UNDO et REDO, mais j'imagine que tout ces termes ne sont pas encore familiers pour un groupie de mysql, renseigne toi, tu vas le voir, le rapport. Pour le reste, libre a toi de penser que tu es à l'abris avec lvm. Je te dis juste un truc: ce n'est pas aussi simple.
-
[^]Re: backup
Posté par Gloo () le 26/09/2002 à 20:12. (lien). Évalué à 1.Je termine sur ce post (à moins que tu relances un troll sur un autre sujet...). Je n'arrive décidemment pas à mettre la main sur le fameux thread qui parle du hot backup de mysql et de LVM. Néanmoins, comme tu n'as pas l'air de vouloir comprendre que j'ai une certaine expertise sur ces problèmes, j'ai trouvé un autre lien. Un ingenieur qui travaille chez yahoo finance et qui bosse sur mysql va sortir un bouquin chez O'reilly (Advanced Mysql ou un truc du genre). il a fait une conference dont les slides sont ici: http://jeremy.zawodny.com/mysql/mysql-backup-and-recovery.html Il dit: "Filesytem Snapshot [...] Doesnt guard against all failures" "InnoDB on-line Backup [...] Costs extra $$$ [...] The only good solution for InnoDB backups without replication" Bref, payant, proprio et lvm + mysql marche mal.
-
-
-
-
[^]shutdown
Posté par Moby-Dik () le 26/09/2002 à 10:12. (lien). Évalué à 0.Le vacuum est un mauvais exemple. Avec un design correct avec DES bases (enormes style http//www.geocrawler.org/ qui tournait bien avant la version 7) ce n'est pas un vrai problème. Par ailleurs, vois-tu, c'etait le moment de faire les backups. Ah parce que pour toi ce n'est pas un problème d'arrêter une base de données le temps de l'optimiser ? C'est qui le "rigolo incompétent" ?
-
[^]Re: shutdown
-
-
[^]Re: retourne jouer aux billes.
-
-
[^]Re: retourne jouer aux billes.
Posté par Olivier Jeannet () le 26/09/2002 à 00:44. (lien). Évalué à 1.Côté stabilité, les versions antérieures à la 7.0 étaient de plus réputées (y compris encore une fois du côté des pro-postgres) contenir beaucoup de bugs, problèmes de stabilité et autres crashes.
Je n'ai pas assez utilisé Postgres 6.5 à l'époque, car je suis vite passé à la 7.0 quand elle est sortie. Et j'ai vite remarqué une sacrée différence de performance, sur des bases pas très compliquées ni très grosses : un facteur au moins 2.
En tous cas avec la version 7.0, elle a atteint une très bonne stabilité, je l'avais mise sur un serveur bi-proc et une petite dizaine de personne y accédait (depuis Java 1.2 et driver JDBC), et il y a rarement eu des problèmes.
-
-
-
-
[^]Re: Humm
Posté par matiasf () le 25/09/2002 à 21:56. (lien). Évalué à 2.Suis pas d'accord avec tout ...
> ca permettra à une horde de developpeurs de seconde zone d'enfin (!) s'appercevoir que gerer des transactions au niveau applicatif,...
C'est effectivement de la connerie pour des applis un peu conséquente. Type une base de donnée éditée via VB et depuis le web. Ajoutes à çà des outils généraux d'accès aux bases de données (type MS-Acces que l'utilisateur veut pour faire des rapports perso) et tu aboutis obligatoirement au bout de 2 semaines grand maximum à un enorme "merdié".
> la doc de MySQL melangeant allègrement ce que fait/fera la stable/beta/alpha.
J'ai utilisé MySQL pour du web (hébergement domicile, mais les sites étant petits, c'est pas un problème ).
J'ai donc lu la doc de MySQL. Ce qui me gonfle (ou gonflait car j'ai pas lu de doc récente) avec doc MySQL c'est le FUD qu'il font pour expliquer que les transactions on peut s'en passer, que l'intégrité référentielle peut se faire avec 2 lignes de php, pouquoi utiliser un truc compliqué (style PostgreSQL) et qui n'apporte rien, etc, etc...
Bref tout ce que n'a pas MySQL ne sert à rien, et ce que n'avais pas MySQL ne servait à rien et est devenu "d'un coup" indispensable.
> PostgreSQL est trop meconnu
On ne le répètera jamais assez.
J'espère que RedHat avec leur offre de base de donnée basé sur PostgreSQL va aider améliorer sa popularité.
Il faut relativiser et ne pas mettre en conflit MySQL et PostgreSQL. MySQL est populaire car très utilisé et avec des points fort :
- free.fr le fourni !
- système de sécurité souple (table db, host, user, etc... de la base mysql).
- de bon driver odbc qui permet à mysql de fonctionner correctement avec MS-Acces.
- Marche très bien sous windows (serveur et client). Y a un port du serveur postgresql sous windows mais il n'ai pas autant "suivi" que celui de MySQL.
- Simple, lisible. chaque base de donnée est dans son propre répertoire (un truc très pratique pour les "gros" fournisseur d'accès type free.fr).
- etc...
J'aime bien mysql. Mais pour un truc complexe (complexe ne veut pas dire gros ou problème de monté en charge !) ce n'est pas un bon chois.
PS : quand j'ai un post un peu long, j'ai squid qui me retourne un truc style "zero size reply" lorsque je valide et çà ne marche pas mieux dans squid.
Pour ce post j'en suis à plus de 20 tentatives !-
[^]Re: Humm
Posté par Gloo () le 25/09/2002 à 22:46. (lien). Évalué à 1.[VB-Access]
Moi je pensais PHP-MySQL ;)
"tout ce que n'a pas MySQL ne sert à rien, et ce que n'avais pas MySQL ne servait à rien et est devenu "d'un coup" indispensable"
MySQL a gardé ce je-ne-sais-quoi de son époque proprio. La première version GPL de MySQL date d'aout 99. Oh ! juste après l'award de postgreSQL... Ca doit être une coincidence... Ceci dit à cette epoque dans ma boite il y avait des postgres 6.5.? en prod. Et ce passage GPL de mysql m'a bien fait marrer à l'époque vu le retard que mysql avait, a jusqu'à aujourd'hui, et pour longtemps encore.
"ne pas mettre en conflit MySQL et PostgreSQL"
Ce n'est pas ce que je fais. Ca me saoule que l'on compare l'incomparable et qu'on raconte n'importe quoi sur postgreSQL.-
[^]Re: Humm
Posté par matiasf () le 25/09/2002 à 23:15. (lien). Évalué à 1.> Moi je pensais PHP-MySQL ;)
Je sais pas si je me suis fait comprendre.
Je voulais dire que la puissance de PostgreSQL/Oracle/... est interressante (voir indispensable) dans le cas où il y a plusieurs systèmes pour éditer une base de donnée.
S'il n'y a qu'une interface web + php pour éditer la base de donnée tu peux faire un truc correct car tout les contrôles passe par php (et en codant bien il n'y a pas de doublon dans les codes de contrôle d'intégrité). Mais si tu as plusieurs systèmes d'édition, il faut dupliquer les contrôles. De plus, mon exemple avec Access (ou Object Business, etc...) avec un utilisateur qui veut faire ses propres rapports/requêtes voir formulaires spécialisés est le cas typique où t'es OBLIGE d'utiliser une bonne palette des fonctionnalités de postgresql. TOUS les contrôles, actions liés aux données doivent être fait par la base de données (et non par php ou VB ou autre).
-
-
-
[^]Re: Humm
Posté par Sylvestre Ledru (Jabber id, page perso, ) le 26/09/2002 à 00:18. (lien). Évalué à 5.Experience perso :
J'ai eu a bosser sur le code PHP/Postgresql pour un gros site (le site est pour un des leaders mondiaux du luxe).
Donc dans ce projet, il y avait une quantité d'enregistrement relativement importante (8000).
Donc pour le développement, nous avons travailler sur un serveur Linux avec une version recente de PSQL (c'etait la 7.X), donc tout marchait bien et rapido.
Mais au moment de le passer sur le serveur du client (un gros Sun bien puissant mais avec un Postgresql 6.X), nous avons rencontré deux gros problemes :
- le premier pour les champs txt qui avaient une longueur limité (et trop faible : 8000 caracteres si je me rappelle bien)
- le second pour la lenteur de traitement (on avait vraiment le temps d'aller se chercher un café pendant le traitement (pourtant, c'etait que des jointures dans l'essemble) : ca durait plus de 30 secondes contre 1-2 sur la version 7.X.
Nous avons donc demandé un changement de version qui a ete fait quelques jours apres, et tous les problemes ont été corrigés grace a ce changement ...
Je ne tire pas de généralité sur mon expérience, mais si le code a ete en grande partie réécris d'une version a l'autre, c'est qu'il doit y avoir une raison :)
Apres, a titre personnel, je prefere beaucoup plus utiliser Postgresql que Mysql pour un paquet de raisons.
Ensuite, en dehors du coté performance (il faut comparer ce qui est comparable), ca fait mal a dire, mais Oracle et MS SQL server ont quand meme toujours quelques wagons d'avance sur les deux autres en terme de possibilité.-
[^]Re: Humm
Posté par Gloo () le 26/09/2002 à 02:36. (lien). Évalué à 1."nous avons rencontré deux gros problemes"
Le premier, vous ne pouvez vous en prendre qu'à vous même.
Le deuxieme:
L'optimizer était *vraiment* chatouilleux dans le 6.5.x Pour moi ca c'est toujours resolu en réecrivant les query (ordre des jointures, ordre des attributs...). Faudrait que je retrouve une query avec un NOT IN ou un DISTINCT qui prennait 1+ minutes. Réecrite elle prennait moins d'une seconde... et en v7, plus de problème.
Après il y a les blagues du type 32 connexions max par default, faire un vaccum après avoir recrée les indexes, ou les blobs pas sauvegardés enfin bon... Il y a des gens qui ont suivi (postgresql) et qui connaissent un tas d'astuces, d'autres qui trouvent que tunner une base est inacceptable, ou plutôt qui n'ont pas compris que DBA était un metier(necessaire).
"si le code a été en grande partie réécris d'une version a l'autre"
Je veux bien que tu me pointes sur des liens qui parlent de réecriture, parcequ'à part de nouvelles "grosse" implementation comme le WAL, je ne vois pas.
"[oracle et mssql]"
ils ont le type boolean SQL99 maintenant ? ;) Sinon d'accord avec toi, reste a savoir si les possiblités offertes ne sont pas overkill (et hors de prix !)
Merci de m'avoir rappelé le coup des 8k, et du coup, un tas de bons souvenirs-
[^]Re: Humm
Posté par Sylvestre Ledru (Jabber id, page perso, ) le 26/09/2002 à 05:13. (lien). Évalué à 2.Pour le premier point, s'en prendre a nous meme ?
Oui, mais nous n'etions pas au courant que c'etait une vieille version qui etait dessus.
Et bon, meme access 2.0 gere sans aucun probleme 65000 caracteres. (ceci dit, j'avais vu des solutions pour parer ce pb avec PSQL, et c'était assez rigolo)
Perso, c'est pas dans mon habitude de programmeur de regarder ce que les anciennes versions ne geraient pas.
Ensuite, l'optimizer, c'est grosso modo le "débat" sur ce que la machine doit faire et ce que le programmeur doit faire par lui même.
L'optimisation SQL est fondamentale pour des gros sites. (je regrette de ne pas avoir eu de cours là dessus ...) mais le fait que l'optimiser de Postgresql marchait aussi mal montre que l'utilisation en prod devait rester assez marginale ...
Pour les liens, désolé, je retrouve pas, c'est ce que j'avais lu sur certains sites mais je me trompe peut etre...-
[^]Re: Humm
Posté par Gloo () le 26/09/2002 à 17:48. (lien). Évalué à 2."Oui, mais nous n'etions pas au courant que c'etait une vieille version qui etait dessus" C'est de la faute de postgresql ou de la votre ? :) "la machine doit faire [...] le programmeur doit faire" Tu oublies quelqu'un dans l'histoire. Un dba ? ou au moins quelqu'un qui connait bien la base de données sur laquelle vous travailliez, qui a suivi sont histoire, connait ses limitations, comment les contourner... "le fait que l'optimiser de Postgresql marchait aussi mal" Je ne suis pas franchement d'accord. Il marchait plutôt bien, sauf dans certain cas, relativement bien defini, très mal. "utilisation en prod devait rester assez marginale" Encore une fois, il y a des liens au dessus et des archives de mailing list qui attestent que non (sans parler de mon experience). Alors oui, dans les web agency c'est marginal, mais le monde du web ce n'est pas tout, et c'est même marginal par rapport à l'ensemble des autres activités.
-
[^]Re: Humm
Posté par Sylvestre Ledru (Jabber id, page perso, ) le 27/09/2002 à 00:03. (lien). Évalué à 1.quelqu'un qui connait bien la base de données sur laquelle vous travailliez, qui a suivi sont histoire, connait ses limitations, comment les contourner... Tu ne m'as pas compris. Nous bossions sur notre serveur de test avec la version 7.X. (nous pensions qu'ils tournaient avec une version équivalente que la notre). Personnellement, je l'ai deja dis au dessus, quand je bosse avec une version d'un SGBD, je regarde les features de la version courante, pas celle de la version précédente sortie quelques semestres avant (peut etre que j'ai tord de ne pas faire cela, mais j'en doute ...), dans mes développements, je m'en fous un peu de savoir Mysql 1.2.34 ne gérait pas les GROUP BY (supposition). Surtout que bon, j'avais déjà utilisé Oracle, Access, Mysql et MS SQL Server dans divers projets, donc je m'estimais suffisamment callé pour celà. Je ne suis pas franchement d'accord. Il marchait plutôt bien, sauf dans certain cas, relativement bien defini, très mal. Tu es pas d'accord, c'est ton droit. Moi, je trouve qu'un SGBD qui augmente par un facteur 30 le traitement d'une requete contenant 3 jointures et un DISTINCT sur des tables contenant un nombre d'enregistrement raisonable, c'est pas "normal". (alors que même access, tant décrié par une partie de la communauté developpeur, n'a AUCUN mal à gérer ça avec une vitesse de traitement tout a fait potable) Encore une fois, il y a des liens au dessus et des archives de mailing list qui attestent que non (sans parler de mon experience). J'avoue, j'ai pas ete voir les URLs vu les reponses qui ont suivis dans la tribune. Alors oui, dans les web agency c'est marginal, mais le monde du web ce n'est pas tout, et c'est même marginal par rapport à l'ensemble des autres activités. Sans dec ? :) Moi qui pensait que l'informatique actuelle, c'était plus que PHP / ASP... Je te fais remarquer que j'ai fait comme toi, j'ai fait que parler de mon expérience, rien de plus.
-
[^]Re: Humm
Posté par Gloo () le 27/09/2002 à 04:16. (lien). Évalué à 1."Tu ne m'as pas compris" si si, je t'ai bien compris. Vous bossiez sur la 7, ils etaients sur la 6.5.x. Et, en fin de projet ,on s'appercoit qu'il y a des problèmes. Ce n'est pas le developpeur qui est en cause vis à vis de ses 2 dysfonctionnements. "j'avais déjà utilisé Oracle..." Avec ses varchar2 de 4k ? :) C'est dingue tout de même, plus ca coute, moins ca rale. héhé :o) "les reponses qui ont suivis dans la tribune" Je ne lis pas la tribune. Enfin bon, je suis le premier à reconnaitre qu'il y avait des limitations et qu'il fallait connaitre le soft. En revanche, quand je lis des "avant la 7 [...] beaucoup de bugs, problèmes de stabilité et autres crashes [...] rigoureusement inutilisé en production", là je me dis que la personne n'a pas connu cette periode puisque cela ne reflète ni mon experience, ni les faits (cf liens , archives et projets de l'époque...)
-
[^]Re: Humm
Posté par Sylvestre Ledru (Jabber id, page perso, ) le 27/09/2002 à 05:16. (lien). Évalué à 1.je me dis que la personne n'a pas connu cette periode puisque cela ne reflète ni mon experience C'est un argument ça ? Si ca n'en n'est pas, le mot "puisque" est bien mal choisi. ni les faits (cf liens , archives et projets de l'époque...) Je vais pas le refaire, les autres l'ayant deja fait, mais tes liens et les urls que tu as donné au dessus, tu crois vraiment qu'elles supportent ce que tu essaye de nous convaincre ? (parce que bon, l'historique de Psql, c'est pas une source terrible ... et le prix OpenSource, sorti de Postgresql à l'époque, il y en avait d'autre ?)
-
-
-
-
-
[+] [^]retour de troll ;-)) (-1)
Posté par Moby-Dik () le 26/09/2002 à 10:27. (lien). Évalué à -2.Après il y a les blagues du type 32 connexions max par default, faire un vaccum après avoir recrée les indexes, ou les blobs pas sauvegardés enfin bon... Jolies blagues en effet. Enfin, c'est bien, tu finis par contredire tes propres affirmations sur l'utilisabilité des versions < 7.0, et à me donner raison sur ce point ;-))
-
[^]Re: retour de troll ;-)) (-1)
Posté par Gloo () le 26/09/2002 à 15:53. (lien). Évalué à 1.Rien de tout ce que j'ai dit plus haut, n'empechait d'utiliser postgreSQL en production. Il suffisait de connaitre les limitations ou les astuces pour les contourner... En revanche, pas de transaction pour un SGBDR, c'est preter ce nom pour un parseur de fichier binaire avec un front-end SQL comme l'est (l'etait ?) MySQL.
-
[^]Re: retour de troll ;-)) (-1)
Posté par Sylvestre Ledru (Jabber id, page perso, ) le 27/09/2002 à 05:41. (lien). Évalué à 1.Je suis pas sur que Mysql ai, dans le passé vu que ca a l'air de changer, prétendu etre SGBDR mais seulement un SGBD. (R voulant dire Relationnel, et Mysql 3.X ne gerant pas du tout le relationnel ...) Ceux qui employent le terme de SGBDR pour Mysql 3.X font une grosse erreur :)
-
-
-
-
-
-
-
-
-
-
moyennement bonne nouvelle
Pour ce qui est de Microsoft, c'est plutôt une bonne nouvelle, puisqu'ils voient en MySQL un concurrent sérieux. Et puis, ils restent cohérents dans leur logique de critiquer tout ce qui ne leur appartient pas.
Par contre, je trouve que c'est bien plus gênant pour IBM. Effectivement (comme le dit Shift plus haut) ils se doivent de mettre en avant leur produit, DB2.
Mais comment réagir face à celà, alors qu'en même temps, IBM promouvoit notre OS favori dans leurs spots TV ?
-
[^]Re: moyennement bonne nouvelle
Posté par Infernal Quack (Jabber id, page perso, ) le 25/09/2002 à 10:04. (lien). Évalué à 8.Mais comment réagir face à celà, alors qu'en même temps, IBM promouvoit notre OS favori dans leurs spots TV ?
IBM est une entreprise et elle fait comme toutes les entreprises : elles va là où on peut faire de l'argent mais elle aime pas non plus en perdre.
-
[^]Re: moyennement bonne nouvelle
-
[^]Re: moyennement bonne nouvelle
Posté par Phil () le 25/09/2002 à 11:41. (lien). Évalué à 8."promeut" pas promouvoit.
Dans le but humaniste d'eviter des fautes de conjuguaison, j'utilise de plus en plus un excellent petit site: le conjugueur; http://www.leconjugueur.com(...)
Opensource est langue de Molière, et c'est plus fort que les binaires! ;-p-
[^]Re: moyennement bonne nouvelle
Posté par Nicolas Tisserand () le 25/09/2002 à 12:07. (lien). Évalué à 2.Outch, je me disais bien que ça criait dans mes oreilles.
J'avais pourtant bien relu l'ensemble pour éviter les trop fréquentes fautes de pluriels et participes, mais là j'ai laissé une belle perle.
Merci de cette correction. +1 pour toi.
Et -1 pour ce post.
-
-
[^]Re: moyennement bonne nouvelle
Posté par vazco () le 25/09/2002 à 11:44. (lien). Évalué à 2.Mais comment réagir face à celà, alors qu'en même temps, IBM promouvoit notre OS favori dans leurs spots TV ?
s/promouvoit/promeut/g
Quand ils font quelque chose que tu estimes bon, tu le dis.
Quand ils font quelque chose que tu estimes mauvais, tu le dis aussi.
C'est si compliqué ?
-
[^]Re: moyennement bonne nouvelle
Posté par Toufou (page perso, ) le 25/09/2002 à 11:53. (lien). Évalué à 1.Mais comment réagir face à celà, alors qu'en même temps, IBM promouvoit notre OS favori dans leurs spots TV ?
Je réagirais comme d'habitude => DB 2 c'est proprio donc c'est Mal, MySQL c'est libre, donc c'est Bien.
-
[^]Re: moyennement bonne nouvelle
Posté par gnap gnap (page perso, ) le 26/09/2002 à 12:01. (lien). Évalué à 1.« Pour ce qui est de Microsoft, c'est plutôt une bonne nouvelle, puisqu'ils voient en MySQL un concurrent sérieux. » Heu..; Tu considère msql (de microsoft) comme un SQL sérieux ??? Ca te ferais quoi si MS annonçait qu'il considère Apache comme un concurrent sérieux... ?
L'annonce officielle MySQL
L'annonce officielle :
http://www.mysql.com/press/release_2002_11.html(...)
et en prime un comparatif remporté par Oracle et MySql au détriment de DB2 et SQLServer ... (ceci explique cela):
http://www.eweek.com/article2/0,3959,293,00.asp(...)
Mwhaha
"With open-source, you're not going to get a platform that's as reliable or scalable or as secure as what you're going to get with a leading vendor, Tullis said."
C'est bien connu que pour avoir un produit qui fonctionne bien et vite, il faut qu'il soit propriétaire et très cher.
(Tullis c'est le gars de Microsoft)
-
[^]Re: Mwhaha
Posté par tulan (page perso, ) le 25/09/2002 à 10:59. (lien). Évalué à 13.Mouais, mdr là !! :)
Dans un interview au "Windows .Net Server Developer Conference", un vice-président de M$ a déclaré "Nos produits ne sont pas conçus pour la sécurité"
... ils sont pas d'accord entre eux les présidents de Redmond ;)
http://www.futura-sciences.com/news1100.php(...)
Nouvelle
MySQL supporte les transactions ACID
C'est pas vraiment une nouvelle, le gestionnaire de tables InnoDB est là depuis un certain temps. C'est surtout que MySQL le considère désormais comme suffisamment stable pour le promouvoir et le supporter plus ouvertement. Et effectivement, il semblerait qu'InnoDB a des performances intéressantes.
-
[^]Re: Nouvelle
Posté par matiasf () le 25/09/2002 à 10:19. (lien). Évalué à 9.Mysql support les transactions depuis un moment. Le support de transaction était fait avec Berkeley DB.
Mais ce support de transaction était par table uniquement.
Le support ACID impose l'intégrité référencielle et mysql avec innodb support l'intégrité référencielle.-
[^]Re: Nouvelle
-
[+] Troll interne
Hé bien .... Bha où est passé ce bon vieux PBPG ??? Maintenant, sans lui, on est obligé de se lacérer à grands coups de troll vengeurs entre Nousss... Pas cool les gas... PasBillPasGates Reviens !! Bon allez ---> -1 c'etait pour détendre l'atmosphère
Cette page a été générée par Templeet en 0.3136s (dont 0.1097 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.