Pour avoir discuté avec Frédéric BROUARD et assisté à des séances de formation en entreprise, son biais envers SQL Server n'a rien à voir avec une volonté commerciale. Il voit le standard SQL comme étant la vérité absolue et c'est vrai que SQL Server a une bonne implémentation des normes en question, clairement.
Après, faut être réaliste, le gros SQL rempli de procédure stockées ultra transactionnelles de papi DBA n'a plus le vent en poupe. Par exemple, quand on fait du web, c'est surtout beaucoup de CRUD, d'où l'utilité de MariaDB qui marche décemment pour ça, malgré ses nombreux défauts de fiabilité et de cohérence.
La mode est aux microservices et donc aux microbases qui n'assurent plus une forte cohérence de données, voir qui ont des index elastic search asynchrones, mais qui sont hautement scalables et réplicables. Dans ce contexte, payer des licences est un gros problème, car si ton service peut passer de 2 à 10 instances de base de données parce que t'as un pic de charge, faut que tu payes 10 licences en permanence même si tu ne les utilises que pendant les pics de charge. Tu ne veux plus te poser des questions de licences, en fait. Ah mince, le nouveau serveur a X cores de plus que l'ancien, donc faut que je lâche 500 000€ de plus.
De toute façon, aucune base de données n'est parfaite. J'ai vu Saint SQL Server décider de foutre des locks X (exclusifs, lecture seule) sur des pages pas du tout concernées par une requête, pour des raisons totalement inexplicables. Les voies de SQL sont impénétrables.
[^] # Re: Anecdote
Posté par damaki . En réponse au journal Sortie de "The Art of PostgreSQL" de Dimitri Fontaine. Évalué à 6. Dernière modification le 27 août 2019 à 10:54.
Pour avoir discuté avec Frédéric BROUARD et assisté à des séances de formation en entreprise, son biais envers SQL Server n'a rien à voir avec une volonté commerciale. Il voit le standard SQL comme étant la vérité absolue et c'est vrai que SQL Server a une bonne implémentation des normes en question, clairement.
Après, faut être réaliste, le gros SQL rempli de procédure stockées ultra transactionnelles de papi DBA n'a plus le vent en poupe. Par exemple, quand on fait du web, c'est surtout beaucoup de CRUD, d'où l'utilité de MariaDB qui marche décemment pour ça, malgré ses nombreux défauts de fiabilité et de cohérence.
La mode est aux microservices et donc aux microbases qui n'assurent plus une forte cohérence de données, voir qui ont des index elastic search asynchrones, mais qui sont hautement scalables et réplicables. Dans ce contexte, payer des licences est un gros problème, car si ton service peut passer de 2 à 10 instances de base de données parce que t'as un pic de charge, faut que tu payes 10 licences en permanence même si tu ne les utilises que pendant les pics de charge. Tu ne veux plus te poser des questions de licences, en fait. Ah mince, le nouveau serveur a X cores de plus que l'ancien, donc faut que je lâche 500 000€ de plus.
De toute façon, aucune base de données n'est parfaite. J'ai vu Saint SQL Server décider de foutre des locks X (exclusifs, lecture seule) sur des pages pas du tout concernées par une requête, pour des raisons totalement inexplicables. Les voies de SQL sont impénétrables.