Discussion :

[Community Management]

Quels pourraient être les meilleurs SGBD SQL en 2016 ?
Oracle pourrait remporter la palme du meilleur éditeur selon les statistiques de DB Engine


Il existe plusieurs éditeurs de bases de données et les professionnels de chaque secteur de l'informatique ont tendance à spécifier un usage précis à un type de SGBD donné. Par exemple, les développeurs Web se tournent plus vers PostgreSQL ou MySQL, et les programmeurs de logiciels métier et d'entreprise s'orientent sur Oracle ou MS SQL Server.

Cependant, une réelle concurrence se poursuit entre les éditeurs de ces SGBD, avec Microsoft qui rendra bientôt SQL Server disponible sur Linux, pour encore améliorer sa position face à Oracle Database qui, quant à lui, confirme sa stabilité sur plusieurs systèmes d'exploitation.

Selon les statistiques de DBEngine, les SGBD Oracle (Oracle Database et MySQL) sont bien partis pour remporter cette course du SGBD le plus utilisé en 2016, avec une réelle croissance pour MySQL.

Le but de ce sondage est donc d'évaluer lesquels de ces onze SGBD SQL qui sont listés, pourraient être les meilleurs en 2016 sur la base des critères que sont :

• la stabilité ;
• le portage ;
• la performance ;
• le nombre d'utilisateurs en accès simultanés ;
• le support de la communauté et de l'éditeur ;
• la facilité d'installation et de paramétrage ;
• la gestion des transactions ;
• l’intégration IDE ;
• l’interfaçage des pilotes pour la programmation.

L'objectif est de savoir les SGBD que vous préférez et pour quelles raisons vous les avez choisis.

Lors du précédent sondage (Meilleur SGBD Gratuit en 2013), PostgreSQL s'est retrouvé en tête de liste avec 37,7 % de part, suivi de MySQL avec 26,7 % et de Firebird avec 17,5 %.

Vous pouvez choisir un autre SGBD que ceux présentés. Les SGBD NoSQL ne sont pas concernés par ce sondage.

Il s'agit d'un sondage/débat, merci de suivre ces consignes :

• SMS interdit en essayant d'écrire en français ;
• évitez de multiplier les messages courts ;
• les messages type taverne ou SMS seront effacés immédiatement sans préavis ou explications.

Le but est de créer un débat de qualité.



Statistiques DBEngine
Sondage sur le meilleur SGBD gratuit en 2013


Votre avis :

Quels SGBD seraient pour vous les meilleurs en 2016 ? Et pourquoi ?

[grunk]

Le meilleur SGBD c'est celui qui répond à ce qu'on lui demande . En embarqué je vais choisir sqlite pour sa légèreté alors qu'en web j'aurais plutôt tendance à aller sur mysql/mariadb. Si j'ai besoin de gérer des données géographique je vais plutôt aller sur postgres.
Si il y'en avait un vraiment meilleur que les autres , efficace en toute situation , les autres auraient disparus depuis longtemps

[Cincinnatus]

Le meilleur SGBD c'est celui qui répond à ce qu'on lui demande .

C'est pas faux .

En informatique de gestion nous utilisons Oracle SGBD pour les progiciels et les développements associés (sauf PostGre pour une application externe).
En infra, c'est plutôt MySQL.

[hotcryx]

J'utilise MariaDb (Mysql) et franchement elle sort du lot.
Super rapide même sans index et stable.
Le sql en lui même permet des choses qu'Oracle n'apprécierait pas
Rem: je travaille aussi sous Oracle et j'ai travaillé dans le passé avec SqlServer.
Seul point négatif c'est le Mysql Workbench.
Plsql et SqlDevelopper sont très haut dessus.

[Gugelhupf]

Plus que quelques instants avant que SQLpro ne débarque et défende SQL Server avec fougue suite à cette news

[escartefigue]

J'utilise MariaDb (Mysql) et franchement elle sort du lot.
Super rapide même sans index et stable.
Le sql en lui même permet des choses qu'Oracle n'apprécierait pas
Rem: je travaille aussi sous Oracle et j'ai travaillé dans le passé avec SqlServer.
Seul point négatif c'est le Mysql Workbench.
Plsql et SqlDevelopper sont très haut dessus.

C'est une blague

MySQL ne connait pas les CTE, donc pas non plus de requete récursive, pas de fonction de fenêtrage, gestion des verrous très pauvre, le paramétrage des identity column est pauvre, le partitionnement aussi, et j'en oublie
Quand à travailler sans index

[hotcryx]

C'est une blague

MySQL ne connait pas les CTE, donc pas non plus de requete récursive, pas de fonction de fenêtrage, gestion des verrous très pauvre, le paramétrage des identity column est pauvre, le partitionnement aussi, et j'en oublie
Quand à travailler sans index

Tu parles de choses qui ne sont utilisées que par toi et peu dans la pratique pour un codeur d'applic.
Les index je sais c'est quoi, c'est pas pour autant qu'on doit indexer tous les champs, c'est juste une constatation.
Comparant Oracle dans la vie de tous les jours, je vois que MariaDb est plus cool au niveau des queries.

[hotcryx]

Le meilleur SGBD c'est celui qui répond à ce qu'on lui demande . En embarqué je vais choisir sqlite pour sa légèreté alors qu'en web j'aurais plutôt tendance à aller sur mysql/mariadb. Si j'ai besoin de gérer des données géographique je vais plutôt aller sur postgres.
Si il y'en avait un vraiment meilleur que les autres , efficace en toute situation , les autres auraient disparus depuis longtemps

Ouep Sqlite en embarqué fonctionne bien.
Je regrette le temps de dbase III et Clipper

[Shepard]

C'est amusant : Sur le forum, PostgreSQL est en tête avec 35% des votes et 16 participants, tandis que sur la news, MS SQL Server est en tête avec 26,32% et 19 participants, pourtant c'est le même sondage, non ?

edit: OK, c'était un sondage précédent sur des SGBD gratuits (sauf Access, je ne comprends pas bien pourquoi)

[martopioche]

Si il y'en avait un vraiment meilleur que les autres , efficace en toute situation , les autres auraient disparus depuis longtemps

Même si je suis d'accord sur l'intervention, ça, c'est une considération simpliste dans un monde "idéal", car même si on est capable d'identifier un "meilleur", de nombreux paramètres font que d'autres seront choisis comme des choix politiques, des accords commerciaux, des contraintes non techniques, et des contraintes financières…

[Pierre GIRARD]

Le meilleur SGBD c'est celui qui répond à ce qu'on lui demande .

Tout à fait, et pour un usage personnel Firebird demeure mon préféré. Je suis en cours de téléchargement de la version 3.0 et j'ai hâte de la tester.

[a028762]

Il y a aussi le prix et le fait que telle base n'est plus (ou pas encore) open source
J'ai migré de Mysql vers Mariadb quand Mysql a été racheté par Oracle, spécialiste du "closed source".

[LSMetag]

Pour le moment je vais dire SQL Server par rapport aux comparaisons avec Oracle et Mysql. Je n'ai pas fait assez de Postgres pour me prononcé mais je ne suis pas étonné qu'il soit en première place.
Il est, semble-t-il aussi bon que les plus grands, tout en étant OpenSource.

[abriotde]

MariaDB possède les avantages d'une grosse base sans les inconvénients : légereté, facilité de mise en oeuvre, maitrise des coûts, flexibilité... tout en ayant d'immense capacité quand on sait bien l'utiliser. (moteur, index, partitions, configuration...) Nous travaillons sur 20 serveur ayant de gros traitement et qui en plus gèrent chacun une base de près de 2 To de données avec de l'ordre 100 Go minimum qui entrent et sortent (ou bougent (agrégation)) tous les jours. Et, nous sommes loin d'avoir épuiser les possibilités du système. Nous n'utilisons que très peu ses capacité cluster (simplement un peu la réplication maître/esclave et le moteur Connect). PostgreSQL reste meilleur pour ce qui est cartographie.

Oracle c'est juste un gouffre certes efficace mais ingérable. C'est utile peut-être pour 10 bases de données en France. Et encore le CNRS ne l'utilise pas... Peut-être pour Total (elle a les moyen et le temps)

Quand a SQLServer, c'est pour un monde cloisonné de clickodrome innéficace. C'est de loin la plus lente même si c'est peut-être celle qui est la plus simple/polyvalente elle est trop lente pour un informaticien. Elle est capable d'aller faire le café mais il lui faut 24h. C'est utile pour ceux qui ne savent pas faire un programme PHP pour intéroger une base MySQL et y refourrer des données sinon, pour les informaticien il y a le C/C++ et MariaDB.

[mermich]

Je me pose une question toute bete, qui a deja reelement tester les differents services de bdd propose, avec la meme matrice de tests ?

[Chauve souris]

Je me pose une question toute bete, qui a deja reelement tester les differents services de bdd propose, avec la meme matrice de tests ?

SQLPro a testé et comparé les principaux services BDD. Au niveau dialecte (le respect de la norme SQL), fonctionnalités (et insuffisances) et performances. Je ne sais plus où il a mis ça.

[SQLpro]

SQLPro a testé et comparé les principaux services BDD. Au niveau dialecte (le respect de la norme SQL), fonctionnalités (et insuffisances) et performances. Je ne sais plus où il a mis ça.

Juste sur le comparatif PostGreSQL / SQL Server il y a pas mal de choses qui font la différence :
http://blog.developpez.com/sqlpro/fi...lit%C3%A9s.pdf

Bon, il date un peu, mais les 2 SGBDR ont progressé. Donc il reste globalement intéressant.

A +

[escartefigue]

Je me pose une question toute bete, qui a deja reelement tester les differents services de bdd propose, avec la meme matrice de tests ?

J'ai eu l'occasion à plusieurs reprises de traiter les mêmes données sur des SGBD complètement différents, d'une part lors de chantiers de migration, d'autre part pour alimenter des infocentres

L'intérêt dans les 2 cas est d'avoir eu à traiter des volumes significatifs, des centaines de millions à quelques dizaines de miliards de lignes, avec une contrainte forte sur la fenêtre de tir (la plus réduite possible) et d'avoir donc eu à mettre en oeuvre des sauvegrds, des restaurations, des lancement de travaux en parallèle etc...

La limite de l'exercice, est que les 2 plates formes ne sont jamais sollicitées à l'identique, l'espace disque dispo n'est pas non plus le même, les réglages opérés sur l'une ou l'autre machine ne sont pas toujours optimaux, les compétences sur l'un et l'autre système ne sont pas du même niveau, etc...

[Artemus24]

Salut aserf.

Si vous basez votre récupération que sur le raid vous faite comment en cas d'erreur de manipulation de la base qui supprime des donnée ? que faire si vous devez revenir a un état de votre base de donnée a 2 semaine en arrières ?

J'ai surtout l'impression que vous mélangez plusieurs notions bien différentes !

1) cela vous arrive souvent de revenir en arrière, surtout sur une période de deux semaines ?
Je commencerai par m'inquiéter soit dans votre organisation de travail, ou soit dans la conception de votre système d'information.
Je ne dis pas cela pour être désagréable, mais cela soulève réellement un problème de stabilité dans votre façon de travailler.

2) on ne bidouille jamais en direct dans une base de données en production. Cette façon de faire sent l'amateurisme.

J'ai connu quelqu'un qui aimait travailler de cette façon là, venir bidouiller en production. Un jour, suite à une de ces bidouilles, il a planté un système durant 24 Heures !
Plusieurs milliers de francs ont été perdus durant cette journée, où il a fallu revenir 24 heures en arrière, avec bien sûr, des plaintes en cascades de la clientèles. Résultat : il fut renvoyé pour faute lourde !
Mais bon, si vous aimez vivre dangereusement, c'est votre problème.

3) on ne revient jamais à une situation antérieure en production !
Ce dont vous soulevez comme cas de figure, c'est dans un environnement de pré-production, là où vos faites des tests avant la livraison définitive.
Et l'on se sert d'une base de données pour la modifier à sa convenance, et pourquoi pas, revenir à la situation d'origine, pour faire à nouveau des tests.
Il n'est nullement besoin d'avoir des backup pour faire cela, mais juste une sauvegarde, genre dump.

4) je sens la confusion entre un backup, qui en général, se fait sur la totalité d'un disque, que ce soit en incrémentale, en différentiel ou intégrale, avec une sauvegarde qui n'est qu'un vidage de la base de données.

4) je ne parle pas de récupération des données, comme vous le faites, mais de tolérance de panne ! Qu'est-ce que vous ne comprenez pas dans l'expression "tolérance de panne" ?

6) la tolérance de panne sert à rendre un système disponible 24H/24H, même quand un disque dur plante. Cela n'a jamais été destiné à résoudre vos bidouilles dans votre environnement de développement.

Et si votre disque dur vient à planter, que faites-vous ? Vous en commandez un par la poste livrable sous 48 heures ?
Le RAID sert à gérer la tolérance de panne, cela signifie que votre ordinateur et de surcroît votre SGBD, doit être disponible 24H/24H, même si vous avez un disque dur qui plante.

Je ne sais pas si vous comprenez bien ce que représente, financièrement parlant, un système qui ne doit jamais tomber en panne.

la backup est la pour sa.

Le backup ne sert pas à résoudre les fausses manipulations.
Le backup est la solution du pauvre quand on n'a pas les moyens financiers, pour se payer un système à tolérance de panne.

Il faut avoir fait un peu d'exploitation pour se rendre compte de l'impact qui peut exister quand on revient à une situation précédente.
Quand on fait de l'exploitation, on fait une sauvegarde de l'environnement avant de démarrer les batch de nuit. C'est une sécurité !
En cas de plantage d'un traitement, il faut être capable soit de résoudre ce problème, ou soit de revenir rapidement à la situation précédente.
C'est pourquoi, on se laisse durant la nuit, le temps de réparer les conneries qui peuvent arriver, et elles peuvent être nombreuses.
Mais tant que cela reste de la manipulation, c'est juste une perte de temps, et non une situation bloquante.

La situation bloquante est la plus problématique pour une entreprise car cela va se chiffrer en milliers d'euros de perte durant la journée qui sera perdue.
Que faites vous si votre disque dur vient à planter ? En tolérance de panne, ce n'est qu'un désagrément, car il en reste d'autres qui fonctionnent encore.
Vous avez le temps d'aller en chercher un autre et de l'installer.
Mais si votre système n'est pas conçu pour la tolérance de panne, que faites-vous ?

Même le backup dont vous parlez, se fait aussi dans une conception de tolérance de panne, sur un site dédié à cela et non dans votre entreprise.
Imaginez aussi que votre entreprise vienne à brûler, comme le cas du crédit lyonnais en 1996.
Cela n'a eu aucun impacte sur les comptes des particuliers, et ce, à cause de cette sécurité !

J'ai toujours adoré les gens qui me prenne de haut ....

Je ne vous prends de haut, comme vous dites, mais votre façon de vous exprimer dénote un manque d’expérience dans votre façon de travailler.
Et pourquoi cette réaction ? Croyez-vous être le seul à détenir une quelconque expérience et de ce fait, à être le seul à détenir la vérité ?
Nous sommes ici, pour partager nos expériences et notre façon d'aborder certaines questions.

Je me suis mal exprimée sur les tables temporaire, ce ne sont pas des table temporaire au sens sgbd (comme # ou ## dans sql server) mais plutôt des tables normale, qui contienne des données temporaire qui on été généré la nuit par exemple. c'est souvent le cas des gros erp ce qui permet d'avoir des statistiques aplatit pour évité de mouliner de grosse requête lors de chaque interrogation.

Excusez moi, mais si vous dites "table temporaire", je ne peux pas comprendre que vous me parlez de tables de travail avec des données servant juste à la transition dans un traitement.
Pour bien se faire comprendre, il vaut mieux s'exprimer correctement, sinon gare aux incompréhensions !

J'étais tombé une fois sur un cas qui me semblais insoluble sans les CTE, je vais essayer de le retrouvé, et si je le retrouve et tu me montre la requête standard je suis preneur.

Oui, je veux bien !

pour la performance, il m'est aussi une fois arrivé de faire un requête CTE qui était plus rapide que la requête standard. je vais également essayer de te retrouvé cela. c’était une requête CTE qui effectuais un delete dans une base de donnée de plusieurs 100 de millions de ligne, et la requête standard n'arrivais tout simplement pas à s’exécuter.

Je pense que tu fais un mauvais usage des CTE. On se sert du CTE pour faire en cascade, des requêtes.
Il se peut aussi, qu'il y a une mauvaise conception de ta base de données, ou encore, des index qui manquent, ou je ne sais quoi d'autre.

Il existe parfois des solutions auxquels on ne pense pas de prime abord. Par exemple, dans le cas de la suppression des doublons, il existe l'astuce de créer un "create ignore unique index" (sous mysql) sur les colonnes en questions. Cette solution est très très rapide, bien plus que de faire une requête.

Évite de prendre les gens de haut dans une conversation. ou de supposé ce que je sais ou en sais pas.

Je ne voie pas pourquoi je devrais changer ma façon de m'exprimer, surtout que je n'ai pas été insultant. Et je n'ai pas été condescendant, non plus !

Surtout quand on propose comme solution de backup de faire un RAID ;-)

Dans plus de 99% des cas, on ne restaure pas les backup utilisés. Oui, mais on les utilise quand ?
Et bien, en cas de plantage du disque dur ! C'est le cas le plus courant. C'est ce que je qualifie la solution du pauvre, car l'investissement est peu onéreux.
La solution, pour éviter ce genre de désagrément, est le RAID --> tolérance de panne !
Ce que tu nommes backup est en fait une sauvegarde (le dump).

Je n'ai jamais dit que le RAID était une solution de remplacement soit à la sauvegarde (dump) ou au backup (recopie physique du disque dur).

@+

[aserf]

Pour vous repondre,

1) oui cela peu arrivez, votre base de donnée vie, elle ajoute/modifie/supprime des lignes, des fois pour comprendre il peut etre important de restaurer un backup a un instant donnée par exemple entre l'arrivé d'un fichier et la le debut de sont traitement , vous vous rendez compte 2 semaines apres d'un probleme, vous voulez rejouer en debug votre probleme, le seul moyen est de remettre sur un serveur de test la base un instant donnée, defois a la seconde pres, seul le backup le permet.

2) je n'es jamais dit que je bidoullais directement dans la base de donnée de production... relisé mon point 1
3) bhein pareil relisé le 1, et vous faite un dump toute les seconde pour tomber au moment de votre probleme ? je ne sais pas comment vous allez faire ...
4) relisé mes point précedent.
4 bis) pareil
6) qui parle de bidouille dans l'environnement de production, relisé mon point 1
pour la partie financiere, je la connais parfaitement, j'ai acheter une Compellent SC8000 pour stocker mes donnée (160 to) vous devez bien vous douté que tout le monde ne fait pas des site web ...
il y a aussi des société qui travail pour des banques, des assurences, des opérateur téléphonique, ... dans ce cas la notion financière est abordé, mais perdre une 1h de data ou de connexion est largement plus préjudiciable.
de plus ces societes vous forces dans vos contrat a vous engager sur un PCA ou PRA.

cette phrase me fait comprendre beaucoup de chose : "Et si votre disque dur vient à planter, que faites-vous ? Vous en commandez un par la poste livrable sous 48 heures ?"
bhein dans tout system professionnel (baie de stockage) des intevention 4h voir 2h sont proposé ... je pense que effectivement vous n'avez jamais travaillé dans ce type d'environnement.

et la on touche le fond , revoir mon cas 1... pour la réponse :Le backup est la solution du pauvre quand on n'a pas les moyens financiers, pour se payer un système à tolérance de panne.
je pense que vous devriez clairement changé de métier ... le backup est juste le seul moyen de revenir a un instant T (certaine baie le permette également, avec des snapshot, mais on ne vas pas élargir le débat, car si je vous parle de baie a 1 millions d'euro vous allez faire un sincope)

je pense que vous utilisez les serveur sql dans contexte particulier, et vous n'avez pas utlisé dans un contexte professionnel, ou pas dans un contexte ou vos clients on ces exigences.

et comme dit, arretter de me pendre de haut, "J'ai surtout l'impression que vous mélangez plusieurs notions bien différentes !" je pense que ce n'est pas le cas.

J'ai deja,
- installer des serveur,
- des serveur sql,
- baie san,
- environnement virtualisé (VmWare, HyperV),
- developper des driver de base de donnée pour en optimisé les performance avec deconstruction de requette a la volé (sql server et mysql) permet quand même de divisé les temps d’exécution par 1000 ...
- developper des systeme permettant d'executer de la compilation dynamique directement dans les requettes sql (sous sql server)
- Developper des driver de base de donnée pour faire du tunneling http compatible avec les factory de microsoft
- developper un logiciel capable de faire des test unitaire sur les base de donnée
- Des outils d'analyse de parque machine
- Des outils de performance pour les enregistrement des dataset et des schema entity (pareil on divise par 1000 les temps sur certain cas)

je ne prétend pas tout savoir, mais dire que le backup c'est la solution du pauvre a la tolerence de panne fera rire pas mal de personne ... avez vous eu deja des contrainte ISO ? des contrainte de PRA imposé par vos clients ?
revenez un peu sur terre...

merci,