Découvrez les dangers de MySQL et MariaDB, par Frédéric BROUARD (SQLpro) [Tutoriel]

**webMCA** · 25/07/2019, 14h32

Envoyé par François DORIN

On peut tergiverser longuement sur l'origine du nom (est-ce que cela vient de sa fille ou pas), mais cela ne changera pas les problèmes de fond, à savoir les dettes techniques (le coup de la date sous MySQL m'a tué !).

Effectivement. Seulement commencer un article ayant pour but de "démontrer que MySQL/MariaDB n’est pas compatible avec la sûreté, la qualité et les performances attendues par l’entreprise" avec une affirmation fausse (l'origine du nom), il faut avouer que ça ne fait pas très sérieux (même si le reste de l'article est sûrement un peu plus sérieux qu'attaquer mysql sur son nom).
Pour ma part ça mérite au moins une correction...

Envoyé par François DORIN

Oui, l'auteur à fait un article à charge sur MySQL. Mais la réalité, c'est que les fait qu'il a énoncé n'ont pas réussi à être contré. Alors n'arrivant pas à le faire, on s'attaque au messager en lui prêtant les plus mauvaises intentions du monde. Ahhhh triste monde...

Me concernant pas du tout mais je me demande où est la vérité.
Je ne cherche aucunement à contrer ses arguments et j'aimerais bien que SQLPro réponde à mongui concernant son test sur les transactions en mode dirty...

Voilà. pour le reste j'ai appris beaucoup de choses (en premier lieu mon ignorance).
Et je peux tout à fait comprendre qu'utiliser mySQL dans certaines conditions ne soit pas du tout une bonne idée mais comme dit mongui, une certaine neutralité aurait été appréciée...

**webMCA** · 25/07/2019, 14h45

Envoyé par Sebajuste

Monsieur SQLpro, vous avez oubliez les dates avec MySQL ! Alors que c'est ce qu'il y a de plus rigolo !

Pouvez vous trouver comment aboutir à ce résultat, avec cette requête, et cette table ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
CREATE TABLE TEST (
  ID INT PRIMARY KEY AUTO_INCREMENT,
  TEST_DATE DATETIME
);
 
SELECT TEST_DATE, TEST_DATE + INTERVAL 1 DAY
FROM TEST;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
TEST_DATE 	TEST_DATE + INTERVAL 1 DAY
2000-11-30T00:00:00Z 	(null)
2000-11-30T00:00:00Z 	2000-12-01T00:00:00Z

Non, non vous ne revez pas, il s'agit bien de la même date enregistrée ! Pourtant, seule une des deux accepte les opérations de dates...

Voilà la solution !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
INSERT INTO TEST (TEST_DATE) VALUES
  ( STR_TO_DATE("2001-00-00", "%Y-%m-%d") ),
  ( STR_TO_DATE("2000-11-30", "%Y-%m-%d") );

Et ouai, 2001-00-00 donne 2000-11-30 !! ( il faut le savoir lol ). Sauf qu'en fait non... c'est bien une date invalide qui est enregistrée ! Donc on peut l'afficher (et il faudra m'expliquer comment...) mais on ne peut pas faire d'opération dessus.

Non seulement c'est impossible à diagnostiquer (car l'erreur a eu lien à l'insertion...), mais c'est en plus impossible à corriger.

Testé avec SQL FIddle

Désolé, pas réussi à reproduire ce résultat. 2001-00-00 ne donne pas 2000-11-30 !! Ce serait bien de dire sur quelle version de mysql / mariadb ce bug se produit...

Par contre l'insertion sans erreur de "2001-00-00" c'est sûr que c'est moyen...

**Willy_k** · 25/07/2019, 15h43

En jouant avec les modes https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html il est possible d'avoir des comportements un peu plus corrects (empêcher par exemple l'insertion d'une date comme 2001-00-00)

**escartefigue** · 25/07/2019, 15h55

Envoyé par FatAgnus

Le nom n’a d’ailleurs pas été choisi au hasard. MySQL ne signifie-t-il pas que c’est « mon petit business », loin des nécessités professionnelles d’une entreprise ?

Le nom « MySQL » vient du prénom de la fille du cocréateur Michael Widenius, sa fille se prénomme « My ». Ce début illustre bien l'état de l'esprit de l'auteur rempli de préjugés et prêt à enfoncer MySQL à chaque occasion.

Et si tout simplement, le créateur de MySQL avait fait d'une pierre deux coups, en choisissant un nom qui évoque à la fois le prénom de sa fille et également le côté "ma BDD perso" comme le propose SQLPro.
Ce genre d'astuce est fréquent dans le monde de l'édition littéraire, pourquoi pas dans celui des SGBD

**sfavreau** · 25/07/2019, 16h41

Bonjour,

MySQL est présenté comme un SGBDR relationnel et multitransactionnel cependant son implémentation est imparfaite et ne correspond pas exactement à la norme SQL. Les requêtes avec "group by" suffisent pour le prouver et la démonstration de SQLpro est suffisamment détaillé. Cependant cela a été un choix dès l'origine et en effet MySQL ne sera jamais un SGBR relationnel et multitransactionnel comme Microsoft et Oracle l'entendent avec SQL Server et Oracle Databases.
https://aws.amazon.com/fr/relational-database/
Dans le monde libre PostGreSQL respecte mieux le principe du SGBDR relationnel et multitransactionnel.
Une fois que cela est dit, est ce que cela dévalorise MySQL ? Surement pas ! MySQL a son intérêt et d'abord la simplicité de sa prise en main à contrario des 2 leaders. C'est quand même le SGBDR le plus répandu pour la gestion des sites internet. Facebook dont les développeurs sont surement des petits rigolos l'a utilisé pendant longtemps. Concernant le nom du logiciel, celui ci fait en effet référence au prénom de la fille de l'auteur et signifie littéralement "Mon SQL" (à moi) ce qui veut bien dire que cela correspond au SQL que voudrais utiliser le concepteur et non une référence à la norme. Je pense qu'il est préférable de commencer par MySQL puis si on s'intéresse aux SGBDR, on pourra évoluer vers SQL server / oracle.
Je souhaitais revenir sur :

Allez maintenant dans le répertoire de stockage de votre base, par exemple, par défaut, pour MariaDB sous Windows c’est : C:\Program Files\MariaDB 10.3\data.

Vous y trouverez les répertoires des bases, sachant que pour MariaDB/MySQL, une base c’est avant tout un répertoire.

C'est sur ce type d'argument que l'auteur perd sa crédibilité. En effet, il compare une installation Windows Server / SQL Server avec une installation de MySQL sur un environnement W7/W10 + WAMP ou easyphp. Là en effet, on pourra supprimer le contenu des bases mais il s'agit d'un environnement de test et surement pas de production. En règle général et en production avec les bonnes pratiques, MySQL est installé sous Linux et se trouve /var/lib/mysql et là, je suis désolé l'utilisateur sans droit ne pourra pas effacer les bases et supprimant le contenu du répertoire Un utilisateur root oui mais il faudra être root en sachant quand dans les bonnes pratiques il faut créer un utilisateur sans droit et lui donner les droits d'accès uniquement à une base donnée.
Sous windows server c'est un peu la même chose, si on est pas admin, on aura du mal à supprimer les .mdf et .ldf cependant l'élévation de privilèges est plus simple sous windows que sous Unix / linux.

Je suis de l'avis de FatAgnus, on a l'impression que l'auteur est encore sous l'ère Steve BALLMER qui considérait "Linux comme un cancer". Ce n'est plus le discours de Microsoft en 2019, visual studio code est sous linux, sql server lite est sous linux, W10 dispose d'un shell linux, Microsoft est contributeur Linux....

D'autre part, on ne parle pas de l'allocation mémoire de SQL Server, la semaine dernière un éditeur de logiciel m'a demandé de lui mettre à disposition un serveur à 32Go de RAM pour SQL Server. C'est simple désormais, pour remplir 1000 lignes / jour, un serveur SQL Server, c'est minimum 16Go ! Un serveur MySQL avec 4 Go aura des meilleures performances notamment en lecture.

Bref, pour ma part, je considère que MYSQL est un excellent produit cependant c'est vrai que pour des applications très critiques SQL Server sera plus adapté, cependant vu le prix de la licence SQLserver, il est préférable de l'utiliser uniquement quand on ne peut pas utiliser MySQL.

**webMCA** · 25/07/2019, 17h02

Bon, on va essayer d'être un peu sérieux et de clore définitivement la discussion futile (s'il en est du point de vue de l'utilité de cette information) mais néanmoins révélatrice (s'il en est du point de vue de la fiabilité de l'auteur incriminé) sur l'origine du nom :
Source : interview de mars 2013 du créateur Michael Wildenius
Le nom de MySQL vient bien de sa fille My (qui se prononce Mi, il y a un grand débat sur hackernews sur l'origine suédoise du nom et non finlandaise et qui se prononcerait Myeu).
MariaDB vient de son autre fille Maria.

Ni plus, ni moins. Stop.

Si vous pensez le contraire, apportez vos sources.

**fredoche** · 25/07/2019, 20h34

Envoyé par SQLpro

Une entreprise qui vend un produit a une responsabilité légale et obligatoire (défaut de conformité, défaut de vice caché… etc) que n'a pas le monde du libre. Autrement dit, tu peut te retourner contre Oracle, MS ou IBM pour leur imposer de corriger, alors que dans le monde libre c'est juste impossible !
C'est pour cela que certains états d'Europe, autrefois fervent défenseurs du libre, ont désormais imposé des logiciels propriétaires notamment pour tout ce qui est données à caractère personnelles ou sensibles...

A +

euh d'accord

Mais moi je lis ça dans mon contrat de licence pour un SQL server 2017 WEB.
Article 21

LIMITATION ET EXCLUSION DE RESPONSABILITÉ EN CAS DE DOMMAGES. VOUS POUVEZ OBTENIR DE MICROSOFT ET DE SES FOURNISSEURS UNE INDEMNISATION EN CAS DE DOMMAGES DIRECTS UNIQUEMENT DANS LA LIMITE DU MONTANT QUE VOUS AVEZ PAYÉ POUR LE LOGICIEL. VOUS NE POUVEZ PRÉTENDRE À AUCUNE INDEMNISATION POUR LES AUTRES DOMMAGES, Y*COMPRIS LES DOMMAGES SPÉCIAUX, INDIRECTS, ACCESSOIRES OU INCIDENTS ET LES PERTES DE BÉNÉFICES.
Cette limitation concerne*:
· toute affaire liée au logiciel, aux services ou au contenu (y compris le code) figurant sur des sites Internet tiers ou dans des programmes tiers*; et
· les réclamations pour manquement aux termes du contrat ou violation de garantie ou de condition, les réclamations en cas de responsabilité sans faute, de négligence ou autre délit dans la limite autorisée par la réglementation applicable.
Elle s’applique également, même si*:
· la réparation, le remplacement ou le remboursement du logiciel ne compense pas intégralement toute perte subie, ou si
· Microsoft avait ou aurait dû avoir connaissance de l’éventualité de tels dommages.
Certains États n’autorisent pas l’exclusion de garanties ou la limitation de responsabilité pour les dommages incidents ou indirects, de sorte que la limitation ou l’exclusion ci-dessus peut ne pas vous être applicable. Cette limitation ou cette exclusion peut également ne pas vous être applicable si votre pays n’autorise pas l’exclusion de garanties ou la limitation de responsabilité pour les dommages incidents, indirects ou de quelque nature que ce soit.

**chrtophe** · 25/07/2019, 21h32

C'est pour cela que certains états d'Europe, autrefois fervent défenseurs du libre, ont désormais imposé des logiciels propriétaires notamment pour tout ce qui est données à caractère personnelles ou sensibles...

En tout cas en France, l'article 16 de la loi pour une république numérique encourage l'usage du libre. Une circulaire du 1er ministre de 2012 allant dans ce sens.

Ce n'est pas pour ça qu'il faut jeter Oracle/SQL Server en le remplaçant par MySQL/PostGreSQL. Il faut être pragmatique. Déjà changer de produit sur de l'existant fonctionnel va générer plus de problèmes qu'autre chose. Et si le monde bancaire utilise MySQL pour des usages spécifiques, c'est qu'ils y ont intérêt, ne serait-ce que financier.

Et cela ne remet pas en cause l'article qui même si il est orienté contre MySQL, montre des cas à problème. Et l'auteur sait de quoi il parle.

**FreelanceDBA** · 26/07/2019, 00h14

Bon bon bon, par où commencer ?

Premièrement je vais me présenter :
Je suis architecte freelance depuis 4 ans après avoir passé 3 ans au chevet des bases de donnés du groupe Karavel (surtout connu pour sa marque promovacances). Auparavant j'ai roule ma bosse dans le monde oracle principalement pendant 11ans en tant que prestataire de services pour la plupart des grands comptes (PSA, Orange, Air France, BNP Paribas et bien d'autres)
Pour celles et ceux qui veulent ma bio complète elle se trouve en ligne ici même : https://www.linkedin.com/in/sylvain-arbaudie/

J'ai découvert Mysql et MariaDB au sein du groupe Karavel. Après pas loin de 10 ans sur Oracle sa simplicité et ses performances m'ont pas mal séduit. Au point que malgré certaines imperfections, j'ai décidé de me spécialiser sur le sujet.

Deuxièmement je vais annoncer pourquoi j'interviens
Vous l'aurez d'ores et déjà compris je ne viens pas faire le fanboy de SQLpro, je ne serais pas pour autant le toutou de mariadb, je me serais fait embauche si c'était le cas ( poke). J'interviens rarement sur les forums car je n'aime pas la polémique. Toutefois j'ai toujours préféré les faits à la propagande alors on va s'efforcer de remettre tout ça d'aplomb.

Troisièmement parlons désormais des sujets qui fâchent

Un peu de culture ne fait jamais de mal quand on veux parler d'un sujet n'est-ce pas ?

"Mysql aka mon petit business" . My(sql) est le premier enfant de Michael "Monty" Widenius qui est finlandais suédophone au demeurant (Mysql Ab etait bien une entreprise suedoise). Maria(db) est le deuxième. Max(scale) le troisième. L'homme a donc une certaine suite dans les idées si vous voyez ce que je veux dire. cette information figure sur alpage wikipedia dediee a monty, donc accessible gratuitement a tout le monde moyennant une simple recherche google.
Ensuite je vois un amalgame mariadb/mysql. La encore une simple recherche google + wikipedia amene toutes les informations utilesa bien comprendrela difference entre les deux sgbd qui divergent quotidiennement.

Parlons maintenant transaction, acid & and Co.
Je constate que toute la démonstration est basée sur Myisam. Myisam est en effet un moteur de stockage non transactionnel et non ACID. Ces caractéristiques sont connues il n'y a donc la rien de surprenant. Par contre je m'interroge sur ce choix sachant que InnoDB (ou son fork XtraDB) sont les moteurs de stockage par défaut depuis mysql/mariadb 5.5. Innodb est transactionnel et ACID.
Comme indiqué precedemment myisam n'est plus le moteur par defaut depuis mariadb5.5. Or il se trouve que notre auteur utilise le moteur de stockage myisam.il a donc fallu forcer son utilisation pour effectuer la demonstration.
De plus myisam a toujours ete presente comme un moteur non transactionnel non acid. il suffit de faire un simple passage sur la documentation en ligne de mariabd pour l'apprendre. Partant de la quel interet de demonter un moteur de stockage qui reste present a fins de retrocompatibilite, connait quelques usages anecdotques et presenter le tout comme etant le seul moteur de stockage de mariadb ? l'ignorance est exclue car l'auteur utilisant mariadb 10.3, il a fallu forcer l'utilisation d'un moteur de stockage non default afin de realiser cette "demonstration".

Sans être exempt de soucis (les DDL non transactionnels qui forcent un commit implicite par exemple) c'est pour l'instant un bien mauvais procès qui est fait à un SGBDR qui n'en demande pas tant.
Je trouve neanmoins dommage de rédiger un article à charge sur des problèmes factices (collation par défaut, utilisation des modes de fonctionnement, environnement peu voir pas sécurisé, volonté manifeste de ne se soucier du parametrage interne de la base attente sur des identifiant auto générés non vérifiées contre la documentation etc) et de passer à côté des vrais problèmes.

J'ai vu passer une remarque sur les backups non consistants non bloquants. Evidemment il n'ya pas moyen de realiser de miracle concernant myisam pour les raisons qui ont deja ete evoquees. ce sont d'ailleurs les arguments repetes a l'envie par l'auteur. Toutefois xtrabckup et son fork mariabackup realisent bel et bien des backup a chaud, consistants et non bloquants pour les tables utilisant innodb, moteur de stockage, rappelons-le, transactionnel et acid.

Sur une note plus générale à l'open source, je ne trouve pas choquant qu'il y ait autant de CVE. Au moins la liste des bugs et des problèmes de sécurité est connue de tous et toutes. Peux ton en dire autant des systèmes propriétaires ? Non. Il est réalité impossible de savoir à quel point la liste des CVE d'un logiciel propriétaire est bidonnée ou au contraire réaliste. Associons cela au passif de ces entreprises en matière de gestion des bugs, cela ne donne guère envie de les croire soudainement vertueuses.

Passons pour finir sur les histoires de mysql c'est que pour les petits projets.
C'est donc pour ça que booking.com utilise généreusement mysql ?
J'imagine que le groupe Karavel est uniquement composé de gens qui ne savent pas ce qu'ils font ?
J'imagine que cette grande banque française qui utilise mariadb pour son portail corporate non plus ?
Sinon évoquons cette mutuelle nationale qui travaille avec une base mariadb de plus de 1.5To.
Ou encore ce client du mode textile qui assure tout son suivi opérationnel et son reporting depuis ses bases mariadb.
Ou bien DBS bank qui a migré en trois ans l'intégralite de son IT d'oracle a mariadb.
Ou bien Servicenow qui délivre des performances sur des charges phénoménales grâce à mariadb.
On pourrait aussi citer des aéroports, des organismes de paiement, des opérateurs télecoms et bien d'autres encore tout autour du monde qui utilisent mariadb et d'autres encore mysql pour des volumétries variant de quelques centaines de Mo à plusieurs centaines de To. Je ne veux pas dire de betises mais il me semble que la plus grosse base mariadb frôle le Po (et en toute honnêteté vu la chaleur j'ai la flemme de chercher.)

Finissons par le meilleur : Microsoft qui propose dans son propre cloud azure le déploiement de bases mariadb sous forme notamment de cluster galera derrière un proxy maxscale. Notons au passage que Microsoft a fort aimablement accueilli le roadshow MariaDB en ses locaux à Issy les Moulineaux.

Bref tout ceci n'est pas tres serieux et j'en suis bien desole.

"Lorsque nous critiquons, il faut le faire avec une humilité et une courtoisie qui ne laisse subsisteraucune amertume."
Gandhi

**François DORIN** · 26/07/2019, 09h12

Envoyé par FreelanceDBA

Je constate que toute la démonstration est basée sur Myisam.

C'est dommage, car votre post est vraiment détaillé et fourni et aurait pu vraiment faire avancer le débat... si vous n'étiez pas parti d'une assertion fausse !

SQLPro parle bien de InnoDB et non de MyISAM. Je l'accorde, ce n'est pas précisé explicitement dans son article, mais on s'en rend compte assez vite :
- pourquoi parler de clé étrangère si elles ne sont pas supportés ? Il met en avant un exemple pour lequel le système est mis en défaut (utilisation de schémas) ;
- pourquoi parler de transaction si elles ne sont pas supportées ? Il met en avant un exemple dans lequel une transaction est auto-commitée en silence (modification DDL) ;
- pourquoi parler de l'option innodb_large_prefix si on utilise MyISAM ?

Je viens de refaire l'exemple des clés étrangères violées sur un MariaDB v10.3.14 en précisant le moteur InnoDB à la création des tables (car pour une raison inconnue, c'est le moteur MyISAM qui est sélectionné par défaut chez moi). Aucun problème pour créer un enregistrement alors que je ne devrais pas pouvoir le faire.

Envoyé par FreelanceDBA

J'ai vu passer une remarque sur les backups non consistants non bloquants. Evidemment il n'ya pas moyen de realiser de miracle concernant myisam pour les raisons qui ont deja ete evoquees. ce sont d'ailleurs les arguments repetes a l'envie par l'auteur. Toutefois xtrabckup et son fork mariabackup realisent bel et bien des backup a chaud, consistants et non bloquants pour les tables utilisant innodb, moteur de stockage, rappelons-le, transactionnel et acid.

SQLPro a pourtant argumenté longuement dessus. L'aspect consistant et non bloquant (sans avoir à monter une usine à gaz) est conceptuellement impossible vu la structure même de la BD.

**DarkCenobyte** · 26/07/2019, 09h33

Envoyé par François DORIN

Je viens de refaire l'exemple des clés étrangères violées sur un MariaDB v10.3.14 en précisant le moteur InnoDB à la création des tables (car pour une raison inconnue, c'est le moteur MyISAM qui est sélectionné par défaut chez moi). Aucun problème pour créer un enregistrement alors que je ne devrais pas pouvoir le faire.

SQLPro a pourtant argumenté longuement dessus. L'aspect consistant et non bloquant (sans avoir à monter une usine à gaz) est conceptuellement impossible vu la structure même de la BD.

Dans ton my.ini il y a un default-storage-engine=MYISAM qui traine, et si tu as une version récente de MySQL installé, c'est soit qu'il conserve un ancien my.ini peut-être, soit que tu utilise WAMP où le réglage par défaut à longtemps et est peut-être encore de forcer à MyISAM au lieu du vrai par défaut sur une installation normal sous Linux: InnoDB.

http://forum.wampserver.com/read.php?2,137100,137101

Il serait pertinent de dire sous quel OS tout ceci est tester, car WAMP et un MySQL sur un système de fichier NTFS, est très loin d'être la norme d'une prod'...

**François DORIN** · 26/07/2019, 09h51

Envoyé par DarkCenobyte

soit que tu utilise WAMP où le réglage par défaut à longtemps et est peut-être encore de forcer à MyISAM au lieu du vrai par défaut sur une installation normal sous Linux: InnoDB.

Bingo, c'est le cas

Envoyé par DarkCenobyte

Il serait pertinent de dire sous quel OS tout ceci est tester, car WAMP et un MySQL sur un système de fichier NTFS, est très loin d'être la norme d'une prod'...

Windows 10, et MariaDB (pas MySQL) avec WAMP. Maintenant, je concède que ce n'est pas une prod. J'ai juste fait l'installation aujourd'hui sur mon poste pour revérifier (je ne vais pas "polluer" un truc en prod juste pour un petit test

).

Je veux bien croire que Windows 10 + NTFS ne soit pas la norme pour MariaDB (et j'avoue qu'il ne me viendrait même pas à l'idée de faire une installation ainsi, sauf si c'était sur un serveur déjà existant), mais si le moteur InnoDB ne fonctionne pas de la même manière sur un truc aussi gros que les contraintes de clé étrangères en fonction du système de fichiers, c'est un énorme souci de conception !

**Willy_k** · 26/07/2019, 10h01

W10, MariaDB 10.3.11 avec INNODB evidemment.
J'ai tenté une insertion dans une table ayant une clé étrangère et MariaDB me sort généreusement

Erreur dans la requête (1452): Cannot add or update a child row: a foreign key constraint fails (`test_db`.`commentaire`, CONSTRAINT `fk_commentaire_user_id` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE NO ACTION)

**François DORIN** · 26/07/2019, 10h04

Envoyé par Willy_k

J'ai tenté une insertion dans une table ayant une clé étrangère et MariaDB me sort généreusement

Sur deux tables, dans deux schémas différents, avec une clé étrangère entre les deux ?
Car sur deux tables du même schéma, je n'ai effectivement aucun souci.

**SQLpro** · 26/07/2019, 10h16

Envoyé par fredoche

euh d'accord

Mais moi je lis ça dans mon contrat de licence pour un SQL server 2017 WEB.
Article 21

Un contrat est un contrat entre parties. Il ne peut être plus restrictif que la Loi. Toues les éditeurs essayent de minimiser leur responsabilité… Mais en matière de vice caché, et dans le logiciel cela s'appelle un bug, la Loi ne prévoit aucune limitation du montant des dommages.
https://www.service-public.fr/partic...sdroits/F11007
L'appréciation restant toujours au juge sur la "juste" indemnité...

Le fait dans le logiciel libre qu'il n'existe personne pour se retourner rend de fait caduc toute poursuite !

A +

**chrtophe** · 26/07/2019, 10h27

Tout logiciel libre ou propriétaire comporte des bugs. Une fois ceux-ci connus, il sont en général corrigés. Le vice caché est alors corrigé.

Si tu achètes un logiciel, que celui-ci comporte un vice caché t’empêchant de l'utiliser, il est normal que le contrat de vente soit rompu. Un logiciel gratuit, tu n'a rien à te faire rembourser vu que tu n'as rien payé. Là ou ça devient plus compliqué et litigieux, c'est sur les effets indirects d'un bug du produit comme une corruption de données, ou un effet de bord sur une partie du SI autre que la base pour notre exemple. Quel est la responsabilité du vendeur ? mais tu es sensé sauvegarder. Quant à l"installation d'un produit gratuit, vu que tu l'as fait de ta propre initiative, tu es le seul responsable.

**FreelanceDBA** · 26/07/2019, 10h46

Envoyé par chrtophe

Tout logiciel libre ou propriétaire comporte des bugs. Une fois ceux-ci connus, il sont en général corrigés. Le vice caché est alors corrigé.

Si tu achètes un logiciel, que celui-ci comporte un vice caché t’empêchant de l'utiliser, il est normal que le contrat de vente soit rompu. Un logiciel gratuit, tu n'a rien à te faire rembourser vu que tu n'as rien payé. Là ou ça devient plus compliqué et litigieux, c'est sur les effets indirects d'un bug du produit comme une corruption de données, ou un effet de bord sur une partie du SI autre que la base pour notre exemple. Quel est la responsabilité du vendeur ? mais tu es sensé sauvegarder. Quant à l"installation d'un produit gratuit, vu que tu l'as fait de ta propre initiative, tu es le seul responsable.

C'est pour ça que dans le monde libre les éditeurs vendent un support qui permet au client d'avoir un lien de responsabilité et un support technique sur incident (et même bien plus dans le cas mariadb) . Pas simplement un droit d'utilisation à géométrie variable qui permet à peine au client de savoir qu'il aura le droit à un proces de 10ans à l'issue fortement incertaine en cas de problème. Soyons sérieux 30 secondes.

**chrtophe** · 26/07/2019, 10h56

C'est pour ça que dans le monde libre les éditeurs vendent un support

support payant que tu peux avoir aussi hors du libre.

**webMCA** · 26/07/2019, 11h00

Envoyé par SQLpro

Un contrat est un contrat entre parties. Il ne peut être plus restrictif que la Loi. Toues les éditeurs essayent de minimiser leur responsabilité… Mais en matière de vice caché, et dans le logiciel cela s'appelle un bug, la Loi ne prévoit aucune limitation du montant des dommages.
https://www.service-public.fr/partic...sdroits/F11007
L'appréciation restant toujours au juge sur la "juste" indemnité...

Le fait dans le logiciel libre qu'il n'existe personne pour se retourner rend de fait caduc toute poursuite !

A +

Un bon point pour vous SQLPro.
Etant donné que vous êtes un expert de SQL Server, y a-t-il des jurisprudences concernant des clients s'étant retournés contre Microsoft pour des problèmes avec SQL Server et ayant eu gain de cause ? (si oui, de quels montants ?)

Tant que je vous tiens sous les yeux, qui a raison sur cette histoire de clés étrangères violées et de sauvegarde à chaud ?
Parce que pour moi rien n'est clair...

**FreelanceDBA** · 26/07/2019, 11h04

Envoyé par François DORIN

SQLPro a pourtant argumenté longuement dessus. L'aspect consistant et non bloquant (sans avoir à monter une usine à gaz) est conceptuellement impossible vu la structure même de la BD.

J'ai relu le fil de discussion. Il y a très exactement 0 arguments autres que les affirmations de l'auteur sur le sujet et l'évocation d'un cas mysterieux dont nous ne saurons rien sur le pourquoi ça ne marche pas. Pour information 300Go ça se backup très bien. On arrive même à backup des bases de près de 2To sans interruption de service.

Donc j'insiste lourdement sur le fait que xtrabackuo et Mariabackup réalisent bel et bien des backups physiques consistants, à chauds et sans blocage quand on daigne utiliser le moteur de stockage innodb.
Après il est toujours possible de trouver des cas où les utilisateurs font tellement n'importe quoi que c'est impossible à sauvegarder je ne le nierais pas. Toutefois avec un minimum de best practice (la premiere étant pourquoi diable foutre autre chose qu'un produit Microsoft sur un serveur windows) il 'y a pas de souci.

Du coup je suis toute ouïe sur la demonstration théorique de pourquoi il est impossible de faire un backup consistent et non bloquant.

Découvrez les dangers de MySQL et MariaDB, par Frédéric BROUARD (SQLpro) [Tutoriel]

MySQL

Discussions similaires

Partager

Partager