Discussion :

[scheu]

donc et pour un particulier ? tu pense que c'est quoi le plus adapté pour toute utilisation ?

Il n'y a pas de solution unique pour tous les types d'utilisation
Pour une entreprise, je conseillerai toujours Postgresql : plus proche de la norme SQL, avec des fonctionnalitées adaptées aux entreprises (partitionnement, réplication, ...)
Pour un particulier pas forcément initié, mysql est peut-être plus simple

Enfin ça reste mon avis ...

[scheu]

j'ai l'impression que plus le temp passe , plus mysql grimpe sur postgresql (meme si perso je prefere pgsql), par exemple le fait d'avoir plusieurs moteurs de stockage (en contrepartie ils ne sont pas dispo partout , par exemple innodb n'est pas activé sur free), et la syntax parfois plus simple (genre les SHOW pour afficher des informations utile alors qu'on doit generalement passer par un select assez complexe sur postgresql)
par contre au niveau des langages procedurales mysql a l'air toujours en retard :/
j'ai pas vu postgresql beaucoup evolué ces derniers temps (sauf niveau performances depuis la 8.1)
qu'en pensez vous ?

Postgresql évolue aussi, également les contributions (modules additionnels) comme les liens bases de données, le partitionnement, les pools de connexion, les tablespaces, bientôt les transactions autonomes ...
Je ne connais pas bien MySQL mais plus le temps passera, plus les 2 SGBD auront les nouvelles fonctionnalités qui leur faisaient défaut autrefois

[kedare]

.
Je ne connais pas bien MySQL mais plus le temps passera, plus les 2 SGBD auront les nouvelles fonctionnalités qui leur faisaient défaut autrefois

Comme ?

[scheu]

Par curiosité, dans les dernières versions de MySQL, est-il encore possible, sans affichage clair d'un avertissement ou message d'erreur MySQL, d'insérer des dates non valides (ex : 0000-00-00 ou 30 février), ou des champs plus grands que la taille maximale et dont la valeur est tronquée implicitement en base ?

[skuatamad]

Je viens de tester et effectivement c'est toujours possible sur une 5.0.45 même si une date comme le 30/02 est restituée en 0000-00-00.

[kedare]

Je viens de tester et effectivement c'est toujours possible sur une 5.0.45 même si une date comme le 30/02 est restituée en 0000-00-00.

Et si j'ai bien comprit, ça ne devrais pas ?

[SQLpro]

C'est totalement débile !!!! Imaginez ce que cela donnerait en production dans un hopital. L'utilisateur saisi par erreur la date de l'opération du cancer de madame duchemol le 5.0.2008... Cette pauvre dame à toute les chances de crever parce qu'on l'opérera jamais...
Il y a aujourd'hui des informaticiens en prison, parce que les tests d'un appareil de radio thérapie ayant été bâclés, des centaines de malades ont reçu des doses de rayon trop forte en sont maintenant malade....
http://tf1.lci.fr/infos/sciences/san...s-epinal-.html

Peut être étais-ce à cause de MySQL ?...

En tout état de cause je préconise de ne jamais utiliser MySQL dans un développement susceptible d'engager la responsabilité des développeurs ou de l'éditeur (commerce, compta, santé...).
Ces multiples bugs non corrigés, comme son incapacité à faire des sauvegardes consistantes à chaud et sa piètre montée en charge transactionnelle, me rappelle les SGBD fichiers les plus mauvais comme Access ou Hyperfiel !

A +

[kedare]

Dans les cas critiques comme cela, généralement on utilise des sgbdr et langages beaucoup plus sécurisé, par exemple ADA, Erlang, enfin si c'est bien programmé ca devrais être faisable en n'importe quel langage et sgbdr (sauf mysql.. :d)
Si non cette affaire d'appareil radio dangereux, il me semblais que c'etait parceque le système n'avait pas de sécurité materiel contre les rayons trop puissant justement, il y avai une erreur dans le programme, c'est pas la meme affaire, mais c'est dans le même genre
je parle de ca : http://fr.wikipedia.org/wiki/Therac-25

Le matériel ne proposait aucun moyen au logiciel pour que celui-ci vérifie l'état des capteurs et leur bon fonctionnement (contrôle en boucle ouverte)

L'AECL avait négligé certaines étapes liées au test du logiciel

La machine ne possédait pas de dispositif physique pour bloquer le flux d'électrons en mode « haute énergie » si la cible n'était pas en place. La sécurité, à ce niveau, reposait ainsi uniquement sur le logiciel.

Les ingénieurs avaient réutilisés des morceaux de code provenant d'autres modèles. Ces modèles possédaient des sécurités physiques et n'étaient donc pas autant vulnérables aux erreurs logicielles.

Donc pour toi Postgresql est mieux concu que Mysql ?

[SQLpro]

Pour PostGreSQL je modérerais en disant que si les bugs sont moins nombreux, cet outil ne permet pas juridiquement de poursuivre son éditeur en terme de défaillance du SGBD. Autrement dit il faut accorder plus de soins à la phase de tests et être conscient qu'en cas de problème ce sera de la responsabilité de l'entreprise qui aura développé avec. Or plus de temps pour les tests, cela veut sire plus de sous.... Donc entre une licence à payer ou bien quelque mois de salaire...
Autrement dit pour des missions critiques je préfère le SGBDR d'un aditeur connu et reconnu pour son sérieux. Le chois est alors simple : IBM DB2, Oracle ou SQL Server.

Quand à Ada, cela me fait rigoler. J'ai bien aimé ce langage avec lequel j'ai, fait mes études. Mais aujourd'hui le temps réel est essentiellement fait en C ! Quand à un SGBDR RT cela existe, mais reste confidentiel....

A +

[gregory.broissard]

Autrement dit pour des missions critiques je préfère le SGBDR d'un aditeur connu et reconnu pour son sérieux. Le chois est alors simple : IBM DB2, Oracle ou SQL Server.

Complétement d'accord. Je rajouterai juste Sybase à la liste.

[jnore]

Pour PostGreSQL je modérerais en disant que si les bugs sont moins nombreux, cet outil ne permet pas juridiquement de poursuivre son éditeur en terme de défaillance du SGBD.
A +

Ca n'arrête pas en tout cas des institutions sérieuses comme l'IGN de faire confiance à ce SGBDR.

Tout comme moi d'ailleurs !

[jnore]

Qui plus est, je me demande s'il est vraiment possible de prouver qu'un SGBDR propriétaire est coupable d'une perte de données !
Et même si cétait possible, de toute façon il est déjà trop tard!
Quant à un dédomagement de Microsoft ou Oracle, je n'y crois pas du tout. Au maximum, on obtiendra un patch !

[SQLpro]

Quant à un dédomagement de Microsoft ou Oracle, je n'y crois pas du tout. Au maximum, on obtiendra un patch !

Certe les licences en principe s'y oppose, mais la Loi étant la Loi, le défaut de vice caché outrepasse ces dispositions contractuelles. Ce sera au juge d'en décider. Encore faut-il prouver la chose.

Ca n'arrête pas en tout cas des institutions sérieuses comme l'IGN de faire confiance à ce SGBDR [PostGreSQL].

Pas étonnant. Il dispose d'une excellente couche géographique avec PostGis et l'IGN que je sache n'a pas de mission critiques sur ce SGBDR ! (enfin je vais en avoir confirmation puisque mon collègue rudi est en train de leur donner une formation SQL Serve !)

A +

[jnore]

La NASA aussi fait partie des gros USER de Postgres.


Est-ce que votre collègue y va la semaine prochaine?

Non mais plus sérieusement, je comprends vos propos. Dans l'entreprise où je travaille SQL Server est le standard. Certainement que ce que vous dites en est une cause.
Mais personnellement, ce qui me sidère c'est l'application avec laquelle des hommes ont bati ce serveur qui est fiable et élaboré et qui ont tenu à ce qu'il soit libre. Il n'y a que la passion qui peut faire ça !
J'ajoute que j'utilise Postgresql depuis plusieurs années, en toute modestie, et que je n'ai jamais eu de souci.

CDLT

[SQLpro]

Est-ce que votre collègue y va la semaine prochaine?

Rudi y est cette semaine...

Mais personnellement, ce qui me sidère c'est l'application avec laquelle des hommes ont bati ce serveur qui est fiable et élaboré et qui ont tenu à ce qu'il soit libre. Il n'y a que la passion qui peut faire ça !
J'ajoute que j'utilise Postgresql depuis plusieurs années, en toute modestie, et que je n'ai jamais eu de souci.

C'est une excellente remarque. Sur la passion, aucun doute. Sur la difficulté je modérerais la chose. Aujourd'hui les mécanismes basiques comme la gestion du cache, la journalisation des transactions (algorithme ARIES) ou encore le groupage des écriture sont des principes bien connus depuis près de 20 ans (merci à Michael Stonebraker qui a été le physicien des SGBDR en mettant au point toutes ces techniques). Un SGBDR basique est donc facile à développer aujourd'hui. Il en va autrement sur certains points complexes comme l'optimisation, la sauvegarde (partielle, complète, transactionnelle...) ou la gestion des espaces de stockage (partitionnement par exemple). Il y a donc encore beaucoup de boulot pour PostGreSQL à prévoir, et les éditeurs ne lâchent pas si facilement leurs recettes, acquise par des dizaines d'années homme de travail !
Par exemple PostGreSQL n'est toujours pas bon sur la gestion des storages qui ne peuvent pas être taillés sur mesure et correctement administrés.
Il est encore très faible sur la qualité des plans de requête comparé à ce que fait SQL Server. Et il est encore loin d'incorporer des éléments de SQL comme la CTE ou les fonctions de fenêtrage ! Parce que il ne s'agit pas que cela marche.... Encore faut-il que cela soit performant !

A +

[jnore]

Mr SQLPro, j'admire la précision de vos propos, je ne peux rivaliser avec vous ! Si c'était le cas d'ailleurs, je serai au coté de Rudi pour aller faire de la formation à la NASA et à l'IGN !

Vous avez certainement raison sur tous ces points, mais vous savez je suis têtu et certainement un peu breton aussi... J'ai fonctionné sur un coup de coeur* concernant PostgreSQL mais il n'y a pas que pour cela que je l'utilise.
C'est que, étant un particulier mettant à disposition de son entreprise ses compétences en matière de SGBDR, et ne tombant pas dans le piège du piratage, je me suis tourné vers le libre.
J'ai bien essayé Mysql (Objet de ce débat), mais certaines choses m'ont dérangé, qui ce confirment dans les différents posts que j'ai lu jusqu'à présent.
J'ai donc opté pour Postgresql et depuis que je l'utilise (je le rappelle modestement), je mesure à quel point je suis en deçà de ses capacités maxi, ce qui laisse présager pour moi de beaux développements futurs.
Persévérer dans sont utilisation, c'est aussi ma façon de le promouvoir...

Certes, Postgresql n'est peut-être pas encore au niveau des plus grands **, mais petit poisson deviendra grand! Les challenges c'est ce qui fait qu'un second peut parfois passer premier!

Merci pour votre implication dans ce forum et de vos commentaires professionnels.

*Certes, c'est bien souvent contraire à la raison.

** Quoique par rapport à ce que je lis de droite et de gauche, il s'en approche.

[SQLpro]

J'ai donc opté pour Postgresql et depuis que je l'utilise (je le rappelle modestement), je mesure à quel point je suis en deçà de ses capacités maxi, ce qui laisse présager pour moi de beaux développements futurs.
Persévérer dans sont utilisation, c'est aussi ma façon de le promouvoir...

Vous avez parfaitement raison, c'est certainement un excellent choix dans votre cas, avec un volumétrie de données assez moyenne. Je veut dire par là que PostGreSQL se relèvera très bon pour des bases de faibles taille (tenant en RAM) ou de taille moyenne (tenant sur un seul disque, soit moins de 200 Go).
Vous avez aussi raison d'en faire la promotion. Je m'y intéresse aussi de près car il s'agit d'une alternative crédible au monstres que sont SQL Server, DB2 ou Oracle. Notons aussi que Firebird n'est pas loin d'être un challenger de PostGreSQL !

Certes, Postgresql n'est peut-être pas encore au niveau des plus grands **, mais petit poisson deviendra grand! Les challenges c'est ce qui fait qu'un second peut parfois passer premier!

C'est là une différence qui peut se révéler importante ou pas. Par exemple je suis en train de renouveler le système d'information d'une collectivité régionale qui est actuellement sous PostGreSQL. Malgré le contre emploi qu'en a fait son éditeur, ce SGBDR a permis de bon résultat sur une masse considérable d'information (8 millions de lignes collectées par an dans la table de production).
Le seul hic, c'est la haute disponibilité... En effet le système doit pouvoir fonctionner 24h/24, 7 jours sur 7, 365j par an sans aucune interruption. Et là les choses changent !
En effet pour faire cela avec PostGreSQL (de manière synchrone) il faut rajouter des solutions d'éditeur, dont le coût de licence + le coût d'intallation et d'administration dépasse de loin le prix d'une licence SQL Server qui intègre tout cela !
Bien entendu cela va à l'encontre des dispositions ministérielles qui invite à ce que les centres informatiques des collectivités utilisent tant que faire se peut, les logiciels libres !
Or on ne peut attendre lorsque les missions sont si critiques, qu'il en va de la vie humaine.... et cela pour une économie illusoire !

En fait ce qui fait la différence entre SQL Server et PostGreSQL, ce sont tous les outils que l'on trouve en périphérie du moteur de bases de données.
Ce n'est d'ailleurs pas le cas d'Oracle ou DB2, qui depuis des années voient leurs parts de marchés stagner au bénéfice de SQL Server ! En effet ces deux acteurs proposent bien ces add-ons, mais ce sont des suppléments à la licence de base. Ainsi le coût de licence entre Oracle et SQL Server apparait le même pour une solution de base, mais il est plus de 12 fois supérieur si l'on inclus à Oracle tous les modules présent en standard dans SQL Server !
Autrement dit, ce qui m'intéresse dans SQL Server n'est pas tant le moteur, même si je le trouve de la meilleure qualité que tout autre, mais certaines fonctionnalité que l'on ne trouve nulle part ailleurs. Petit exemple, les différentes techniques de hautes disponibilité (j'ai fait un article là dessus sur le site de mon entreprise : http://www.sqlspot.com/La-haute-disp...-avec-SQL.html) pour lesquelles aucun supplément n'est à payer. On pourrait aussi parler de la réplication, du reporting, du stockage OLAP et de l'analyse multidimensionnelle, des bases de données collaboratives via Service Broker...etc. Le problème c'est que beaucoup de personnes voient le SGBDR mais pas ce qui va autour, c'est à dire l'architecture de données et au delà ; l'infrastructure informatique côté données !!!

A +

PS : je serais intéressé que vous me racontiez ce que vous faites au sein de votre entreprise...

[jnore]

PS : je serais intéressé que vous me racontiez ce que vous faites au sein de votre entreprise...

En fait c'est très simple:
Je travaille dans un groupe alimentaire très connu du grand public.
Je m'occupe principalement de la GMAO sur le site dans lequel je travaille.
L'application que j'utilise est EAM d'infor sous Oracle (anciennement Datastream...pour ceux qui connaissent ).
Seulement voilà, ce système est super pour absorber les données mais très pauvre pour ce qui est de leur restitution*.
Par exportation/Importation, j'ai donc mis a dispo ces même données mais avec une forte valeur ajoutée...Graphes, Etats, Planning, Edition de code barres, Gestion de documents (nominaux usine).
Certaines parties de cette BDD sont dépendentes d'importations, d'autres sont autonomes.
Certaines données sont sensibles d'autres moins.
Il s'agit d'une sorte de datawarehouse fait maison, où je fais la part belle au PHP, à l'AJAX et au SQL.
Postgresql est parfait pour cela.

Cordialement.

*c'est souvent le cas des gros progiciels.

[scheu]

C'est totalement débile !!!! Imaginez ce que cela donnerait en production dans un hopital. L'utilisateur saisi par erreur la date de l'opération du cancer de madame duchemol le 5.0.2008... Cette pauvre dame à toute les chances de crever parce qu'on l'opérera jamais...
Il y a aujourd'hui des informaticiens en prison, parce que les tests d'un appareil de radio thérapie ayant été bâclés, des centaines de malades ont reçu des doses de rayon trop forte en sont maintenant malade....
http://tf1.lci.fr/infos/sciences/san...s-epinal-.html

Peut être étais-ce à cause de MySQL ?...

En tout état de cause je préconise de ne jamais utiliser MySQL dans un développement susceptible d'engager la responsabilité des développeurs ou de l'éditeur (commerce, compta, santé...).

Je suis entièrement d'accord avec toi, c'est pour ça que je posais la question initialement. Sans parler de l'aspect légal/juridique, ça me paraît incensé et choquant que MySQL tolère des insertions de mauvaises dates (0000-00-00, 30 février, ...) sans générer de message d'erreur (si je ne m'abuse c'est pareil pour les chaînes trop longues : elles sont tronquées à l'insertion sans erreur il me semble non ?)

Pour la qualité et la cohérence des données on repassera, c'est pour ça que je ne conseillerai jamais MySQL en entreprise, ce SGBD est tout sauf sérieux, c'est tout juste acceptable pour faire un petit site perso dans son coin, et encore ...

J'utilise Postgresql depuis plus d'un an sur des applications de production, le SGBD est cohérent et respecte énormément les normes SQL. Je n'ai jamais eu aucun problème.

[VLDG]

Notons aussi que Firebird n'est pas loin d'être un challenger de PostGreSQL !

Je confirme : Firebird, c'est bien aussi !

Pour ce qui est de MySQL, lisez cela :

http://www.scribd.com/doc/2575733/Th...QL-The-Project