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.
Aller plus loin
- Annonce MySQL (5 clics)
- Critique de MySQL par IBM et Microsoft (7 clics)
- MySQL (5 clics)
- InnoDB (2 clics)
# ce sont deux bonnes nouvelles.
Posté par Le_Maudit Aime . Évalué à 10.
[^] # Re: ce sont deux bonnes nouvelles.
Posté par Obsidian . Évalué à 10.
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 . Évalué à 10.
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 . Évalué à 4.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 2.
[^] # Re: ce sont deux bonnes nouvelles.
Posté par Moby-Dik . Évalué à 1.
[^] # Re: ce sont deux bonnes nouvelles.
Posté par Olivier Jeannet . Évalué à 1.
# Mauvaise nouvelle : les éditeur de base de données ont peur :)
Posté par Infernal Quack (site web personnel) . Évalué à 10.
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
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Mauvaise nouvelle : les éditeur de base de données ont peur :)
Posté par Benjamin . Évalué à 10.
Et puis, quoi de plus rassurant que de payer un gros chèque ?
[^] # Re: Humm
Posté par zeDek . Évalué à 10.
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 (site web personnel) . Évalué à 10.
Alors maintenant que les transactions sont gérées, ça devrait être de mieux en mieux.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Humm
Posté par zeDek . Évalué à 10.
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 . Évalué à 10.
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 . Évalué à 10.
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 . Évalué à 10.
[^] # Re: Humm
Posté par Anonyme . Évalué à 1.
[^] # Re: Humm
Posté par grmbl . Évalué à 1.
[^] # Re: Humm
Posté par David Douard . Évalué à 8.
"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 . Évalué à 8.
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 . Évalué à 10.
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 . É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 . Évalué à 2.
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 . Évalué à -2.
[^] # Re: Humm
Posté par matiasf . Évalué à 2.
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 . Évalué à 1.
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 . Évalué à 4.
"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 . Évalué à 8.
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 . Évalué à 2.
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 . Évalué à 0.
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 . Évalué à 1.
http://www.pgsql.com/user_gallery/stats.php?field=postgresql_versio(...)
[^] # Re: retourne jouer aux billes.
Posté par Moby-Dik . Évalué à 0.
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 :
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 . Évalué à 0.
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 . Évalué à 0.
[^] # Re: backup
Posté par matiasf . Évalué à 3.
[^] # Re: backup
Posté par Moby-Dik . Évalué à 0.
[^] # Re: backup
Posté par Gloo . Évalué à 2.
[^] # Re: backup
Posté par Moby-Dik . Évalué à 1.
[^] # Re: backup
Posté par Gloo . Évalué à 1.
[^] # Re: backup
Posté par Gloo . Évalué à 1.
[^] # shutdown
Posté par Moby-Dik . Évalué à 0.
[^] # Re: shutdown
Posté par Gloo . Évalué à 1.
[^] # Re: retourne jouer aux billes.
Posté par nexus . Évalué à 1.
est ce que tu peux me dire ou trouver ce script perl mysqlhotcopy
merci
[^] # Re: retourne jouer aux billes.
Posté par Olivier Jeannet . Évalué à 1.
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 . Évalué à 2.
> 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 . Évalué à 1.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 5.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 2.
[^] # Re: Humm
Posté par Sylvestre Ledru (site web personnel) . Évalué à 1.
[^] # Re: Humm
Posté par Gloo . Évalué à 1.
[^] # Re: Humm
Posté par Sylvestre Ledru (site web personnel) . Évalué à 1.
[^] # retour de troll ;-)) (-1)
Posté par Moby-Dik . Évalué à -2.
[^] # Re: retour de troll ;-)) (-1)
Posté par Gloo . Évalué à 1.
[^] # Re: retour de troll ;-)) (-1)
Posté par Sylvestre Ledru (site web personnel) . Évalué à 1.
# moyennement bonne nouvelle
Posté par Nicolas Tisserand . Évalué à 10.
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 (site web personnel) . Évalué à 8.
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.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: moyennement bonne nouvelle
Posté par kael . Évalué à 8.
[^] # Re: moyennement bonne nouvelle
Posté par Phil . Évalué à 8.
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 . Évalué à 2.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 1.
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 Anonyme . Évalué à 1.
[^] # Re: moyennement bonne nouvelle -1
Posté par Gloo . Évalué à -1.
# L'annonce officielle MySQL
Posté par Xavier Poinsard . Évalué à 10.
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
Posté par Jean . Évalué à 10.
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 . Évalué à 10.
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
Posté par Moby-Dik . Évalué à 10.
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 . Évalué à 9.
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
Posté par Moby-Dik . Évalué à 2.
# Troll interne
Posté par gosseyn . Évalué à -1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.