Discussion :

[SQLpro]

Le rapport 2024 de l'éditeur américain Red Gate sur l'utilisation des outils de bases de données a été établi à partir de 3849 répondants sur 6 continents dans 15 secteurs pour des entreprises de toutes tailles. La collecte des informations a été réalisée auprès des développeurs, administrateurs de bases de données, professionnels de la fourniture de logiciels, responsables informatiques, directeurs techniques et PDG du monde entier.

Il établit la croissance exponentielle des données à l'ère du numérique.

Les organisations utilisent de plus en plus, différents systèmes de bases de données (de 62% en 2020 à 79 % en 2023) avec comme top 4 Microsoft SQL Server, Oracle, MySQL et PostGreSQL.

Dans les différents classements de cette étude Microsoft SQL Server se taille la part du lion, arrivant en tête dans toutes les catégories en :

• nombre d'instances,
• longévité (donc pérennité),
• diversité d'utilisation (OLTP, NoSQL, séries temporelles, géospatial et graphe)

devant PostGreSQL, MySQL, MongoDB, Oracle, SQLite, MariaDB, Redis, IBM DB2 et ElasticSearch...

Il montre la complexité croissante de l'administration engendrée par la multiplicité des plateformes utilisées.

Il indique aussi que, dans le libre, PostGreSQL est en train de dépasser MySQL et se trouve loin devant MariaDB, tandis que dans le monde commercial Oracle s'effondre.



à lire : The State of the Database Landscape, the 2024 industry report from Redgate

[Waldar]

À prendre en compte que Redgate est un éditeur de logiciel né dans le tooling SQL-Server, ce n'est pas surprenant que leurs contacts qui ont répondu à l'enquête soient en majorité tournés sur SQL-Server.

Si on prend une autre étude avec une autre méthodologie, au hasard celle-là : https://db-engines.com/en/ranking_trend, Oracle reste devant SQL-Server, MySQL devant PostgreSQL etc.

[escartefigue]

Je suis surpris de voir qu'il y a un vote en faveur d'Access , ce SGBD n'est que rudimentaire, il conviendra peut-être à quelques toutes petites entreprises, guère plus.

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

Je suis surpris de voir qu'il y a un vote en faveur d'Access , ce SGBD n'est que rudimentaire, il conviendra peut-être à quelques toutes petites entreprises, guère plus.

On est d'accord qu'Access fait rire tous les professionnels des bases de données.
Mais il reste qu'il est toujours très employés par les néophytes. Il y a un nombre significatif d'applications d'entreprises qui proviennent d'un projet access on the side par des équipes non TI et qui devient incontrôlable à un moment donné, dû aux limites de d'access.

[SQLpro]

À prendre en compte que Redgate est un éditeur de logiciel né dans le tooling SQL-Server, ce n'est pas surprenant que leurs contacts qui ont répondu à l'enquête soient en majorité tournés sur SQL-Server.

Si on prend une autre étude avec une autre méthodologie, au hasard celle-là : https://db-engines.com/en/ranking_trend, Oracle reste devant SQL-Server, MySQL devant PostgreSQL etc.

Effectivement Red Gate est un éditeur de logiciel qui a connu son succès sur SQL Server, mais délivre depuis quelques années des produits axés tous types de bases de données. Comme l'a fait Quest qui était Oracleur pendant longtemps avant de commencer à retravailler ses produits pour d'autres SGBD...

Concernant db-engines.com, cette entreprise ne produit aucune enquête. Elle ne fait que mesurer la popularité des SGBD à travers des sites web plus ou moins professionnels. Popularité ne veut dire ni nombre d'implantation ni volumétrie des bases de données. Elle mesure simplement les demandes des utilisateurs qui ne trouvent pas dans la documentation ce dont ils ont besoin... C'est donc relatif à deux éléments :

• la connaissance qu'ont les développeurs du produit qu'il utilise (formation) et plus particulièrement leur lacune
• la bonne ou mauvaise qualité de la documentation, dont elle tend à mesurer la mauvaise qualité

Certains SGBD ont une documentation lacunaire, comme c'est le cas de MySQL (mais ça s’arrange grâce à Oracle) plus encore de MariaDB ou de PostGreSQL (encore beaucoup de travail à faire)... d'autre ont une documentation pléthorique, comme c'est le cas de SQL Server....

Sur Google, le constat est le suivant, requêtes :

• site:microsoft.com "SQL Server" : Environ 1 790 000 résultats
• site:postgresql.org "postgresql" : Environ 190 000 résultats

Soit 9,5 fois moins de références pour PostGreSQL en documentation que SQL Server...

La complexité et l'hétérogénéité de certains SGBD est aussi en cause... Là ou SQL Server est un produit monolithique dont tous les éléments sont conçus et intégrés par Microsoft et communiquent parfaitement ensemble, certains autres ont, soit acheté différentes entreprises pour combler les lacunes du produit (exemple Oracle avec RMan ou Golden Gate) avec une interopérabilité médiocre, soit fait un développement sans une équipe solide capable de gérer le projet correctement (MariaDB, MySQL, PostGreSQL...) et il en résulte des incohérences dans les objets et des lacunes dans la doc...

L'exemple de PostGreSQL tant au niveau documentation qu'au niveau conception est flagrante... Voici ce que je dis dans un de mes supports de cours :

"
1.2.8 – Documentation et sources

[...]

ATTENTION : la documentation est très laxiste et pauvre en exemple. Sa terminologie est assez hasardeuse. À titre d’exemple elle parle « catalogue » pour désigner la table système pg_attrdef alors que le terme « catalog » est un terme officiel de la norme SQL synonyme de « base de données » et que l’on retrouve dans quasiment toutes les vues du schéma normatif INFORMATION_SCHEMA… Souvent elle parle de « cluster » pour désigner le service PostGreSQL et parfois d’instance. La notion même de « cluster » entre en confusion avec la notion de tablespace… , mais aussi la commande CLUSTER ! Le terme champ est souvent employé alors que c’est de colonne qu’il faut parler… Pour la création des index elle indique une classop (en VF) mais l’explication est donnée dans l’entrée opclass…… Mieux vaut donc croiser les sources afin d’avoir une vision claire des informations et à défaut poster dans les forums.

[...]
1.3 – Vocabulaire

PostGreSQL est doté d’un vocabulaire particulier qui n’est pas celui adopté dans la littérature académique et professionnelle concernant les SGBDR… En voici quelques-uns et leur correspondances ou explications :



Pour éviter la confusion décrite au § 1.2.8 et dans le tableau ci-avant, nous avons décidé de ne pas utiliser le terme « cluster » pour désigner une instance du moteur PostGreSQL. Nous utiliserons systématiquement le terme instance à la place. Sauf pour la commande CLUSTER (car cette commande existe bien !).

De la même façon, nous bannirons le terme relation qui fait partie de la théorie de l’algèbre relationnelles inventé par Franck Edgar Codd le créateur des SGBD relationnels au profit du terme table la plupart du temps, voire par des termes plus spécifiques encore…

En conclusion, nous remplacerons systématiquement les termes :



…car ce sont, soit les termes consacrés par la norme, dans la littérature sur les SGBD Relationnels ou encore par la grande majorité des éditeurs de SGBDR.
"

Ne parlons pas des incohérence du PG/PLSQL de PostGreSQL qui permet de lancer des fonctions dans le SELECT capable de détruire les bases....

Il y a aussi le fait que PostGreSQL c'est un salmigondis de commandes externes (une trentaine en standard, bonjour la sécurité...) ayant chacune leur syntaxe propre... Rien que pour la sauvegarde 3 commandes différentes (pg_basebackup, pg_dump, pgdumpall) + de nombreux paramètres... Alors que dans SQL Server il n'y a qu'une seule commande et elle est interne...

Avec un tel merdier, impossible de s'y retrouver facilement... D’où le grand nombre de questions par rapport à un plus faible nombres d'instance et une volumétrie bien moindre.... Sans parler des aspects ergonomiques (absence quasi totale d'outil graphique pour s'aider...)

L'étude de red gate confirme d'ailleurs une étude plus ancienne que j'avais publié ("Information Week – State of Database Technologie 2016" ) qui classait déjà SQL Server devant tous ces concurrents. Et là il s'agit d'étude en questionnant les clients, pas en mesurant des clics....

A +

[JPLAROCHE]

le choix d'une base de donnée dépend aussi de la machine et de l'OS, alors le vote peut être faussé.
ex: DB2 sur AS400 ou DB2 Sur pc n'a strictement rien à voir, ect...
On pourrait rallonger la sauce , ce servir d'Oracle ou MSsql pour un outil, c'est une absurdité...

Je ne comprends ce genre de sondage ........

[Aspartame]

il n'y a pas excel ?

[philouZ]

Auparavant j'étais sur PostgreSQL et je me suis remis à SQL Server depuis peu. J'avoue qu'il y a des fonctionnalités super intéressantes qu'on ne retrouve pas sur PostgreSQL. A l'heure du RGPD, il est plus qu'indispensable d'avoir une sécurité la plus importante possible sur les bases de données.

Aujourd'hui dans SQL Server, je retrouve le TDE et le masquage dynamique des données, ce qui, en tant que développeur, me simplifie grandement la vie. Plus besoin de penser à masquer les données, mon utilisateur appartient à un rôle particulier qui dit qu'il ne peut pas voir les données. On me vole une base de données sur une clé USB, elle est illisible.

Je veux sauvegarder ma base, un simple "BACKUP DATABASE" suffit à le faire. C'est rapide et efficace.

La base réagit au quart de tour. L'interface de SSMS est bien plus intuitive et pratique que celle de PGAdmin.

Et je ne parle pas de la config du serveur et des paramètres de PostgreSQL qui ne donne vraiment pas envie. Obligé de tourber sur les forums pour essayer d'avoir la base la plus réactive possible...

Bref je suis d'accord avec les résultats de ce sondage.

[SQLpro]

le choix d'une base de donnée dépend aussi de la machine et de l'OS, alors le vote peut être faussé.
ex: DB2 sur AS400 ou DB2 Sur pc n'a strictement rien à voir, ect... ...

IBM DB2 est le seul SGBDR qui n'est effectivement pas le même sur les différentes plateformes.... Pour les autres il existe des différences très mineures, peu perceptibles à l'usage !

A +

[Schouss]

Jamais le sujet du coût n’est abordé ? Je suis super étonné des chiffres. Je ne vois que du sqlserver pour du Powerbi, puis après rien pour d’autre applicatif. Par contre, du postgresql beaucoup, et oracle de moins en moins à cause du coût. Voir quelque client avec encore un exadata mais plus aucun oracle rdms. Bizarre, l’article est au antipode de ma vie réel.

[berceker united]

il n'y a pas excel ?

Je ne sais pas si c'est ironique ou non, mais je suis chez un client ou Excel est vu, utilisé et raisonné comme une base de données jusqu'à aujourd'hui. Ce qu'il se passe, c'est qu'il y a quelque années, ils ont commencé à transférer tout cela dans une base de données (SQL Server), je vous laisse imaginer l'horreur en y voyant des noms de colonnes avec des caractères spéciaux, des espaces. J'avais les yeux rouges quand je voyais cela, mais maintenant j'ai une tranquillité d'esprit car je sais que ces personnes iront en enfer.

[SQLpro]

Jamais le sujet du coût n’est abordé ? Je suis super étonné des chiffres....

Le problème du coût est complexe... En effet ce n'est pas seulement la licence. Il faut raisonner en TCO "Total Cost of Ownership". Pour de très petites bases, MySQL/MariaDB et PostGreSQL sont très intéressant, mais dès qu'il y a du volume ou de nombreux accès, la facture montre très vite...
Ce cout total comprend les licences du produits, des OS, le cout des machines, la consommation d'énergie, le coût infrastructure (bâtiment, clim...), les salaires des DBA, les abonnements à la maintenance / hot line, le coût des arrêts de production...

Et là les choses s'inversent vite dès qua la volumétrie, à quelques niveau que ce soit commence à être importante.

Je prendrais un exemple que je connais bien celui d'une base de volume moyen (360 Go de data) avec quelques centaines d'utilisateurs... À l'époque cout de licence SQL Server avec 8 cœurs en hyperthreading : 6 000 € + Windows 4 000 = 10 000 €
Passé en PostGreSQL la base à plus que doublé de volume... Près de 900 Go ! Certes certaines tables et index étaient compressés... Mais il y a aussi le MVCC de PostGreSQL qui fait du "bloating" 'comme on dit dans le monde PostGreSQL au lieu du terme fragmentation...) Bref la VM a du changé de tarification... + une autre VM pour le pooling avec PGpool. Il y a aussi la durée des sauvegardes... on est passé de 32 minutes à 4 heures ! Le DBA a passé une dizaine de jours pour poser un peu moins de 100 index là ou dans SQL Server on avait passé 1 journée pour en mettre 300... Au bout d'une année le bilan est le suivant :

• SQL Server : 10 000 €, VM à 800 € par mois, DBA : 6 jours par an (450 €) => 22 300 €
• PostGreSQL : 0 €, VM 2100 € par mois, DBA : 16 jours par an (450 €) => 32 400 €

Il n'est qu'à voir les benchmarks officiel du TPC.org pour constater que PostGreSQL n'a jamais publié le moindre benchmark...

A +

[redcurve]

Le problème du coût est complexe... [. . .]

Ma seule question concernant SQL server est Microsoft propose-t-il une offre équivalante à CockroachDB en termes de localité physique des données et la notion de super régions ? Par exemple sur CockroachDB je peux dire telle row est localisé dans la région US et telle autre dans la région ASIE, tout en ayant d'un point de vue logique un seul système cohérent.

https://www.cockroachlabs.com/docs/s...ble-localities
https://www.cockroachlabs.com/docs/s...ata-domiciling

[SQLpro]

Cela existe depuis la version 2000 de SQL Server datant de 2000 avec la notion de bases de données fédérées, au travers un mécanisme appelé FPV (Federated Partitionned View).

Dans le document ci dessous, cela s'appelle "Bases de données partagées évolutives"
https://download.microsoft.com/docum...SQL-Server.pdf

En gros chaque instance est placée là ou on le souhaite et une instance fédérative redirige les lectures et écritures sur le bon serveur en fonction du critère de partitionnement de chacune des tables. On peut alors héberger les serveurs n'importe ou (pas uniquement dans le cloud). L'instance fédérative voit l'ensemble des données "concaténées (vues) pour centraliser les accès.
Il y a 20 ans je suis intervenu sur une instance ainsi fédérée à Monaco (Single Buoy Mooring - Recherche pétrolière) avec 3 instances différentes : l'une à Monaco, l'autre à Houston (Texas) et la 3e à New Dheli en Inde. À l'époque il y avait plus de 3 To de données globalement sur l’ensemble des instances réparti sur plus de 100 bases de données...

A +