IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MySQL Discussion :

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


Sujet :

MySQL

  1. #21
    Membre du Club
    Homme Profil pro
    Développeur Back-End
    Inscrit en
    novembre 2012
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Développeur Back-End
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : novembre 2012
    Messages : 13
    Points : 58
    Points
    58
    Par défaut
    Citation Envoyé par François DORIN Voir le message
    Comme je m'y connais la dessus (je suis ces histoires de près !), je me permets d'intervenir. Effectivement, le SGBD n'est pas la source de la faille. Mais la faille est une conséquence du manque de fonctionnalités du SGBD choisi.

    Le coup du mot de passe stockée en clair par exemple, il faut vraiment le faire exprès avec un SGBD comme SQL Server pour le faire (car il propose les fonctionnalités qui vont bien). Mais il est difficile de faire autrement en utilisant MySQL.
    Je ne suis pas d'accord, MySQL propose aussi des fonctionnalités pour "chiffrer" les mots de passe, et autre données, je pense notamment à PASSWORD(), ENCRYPT(), AES/DES_ENCRYPT(), ASYMMETRIC_ENCRYPT(), etc... .
    (Ces fonctions génèrent des chaînes binaire illisible tel que ˜¯(o 2¤®QŠ¦”jD,=ET£9Z! )
    Mais quand bien même un SGBD ne proposerai pas de chiffrer/hasher nativement, c'est encore une fois la responsabilité première des applicatifs/développeurs de faire le nécessaire, dans un premier temps, côté code.
      6  1

  2. #22
    Responsable Systèmes


    Homme Profil pro
    Technicien maintenance
    Inscrit en
    août 2011
    Messages
    14 995
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : août 2011
    Messages : 14 995
    Points : 34 818
    Points
    34 818
    Par défaut
    Mais quand bien même un SGBD ne proposerai pas de chiffrer/hasher nativement, c'est encore une fois la responsabilité première des applicatifs/développeurs de faire le nécessaire dans premier temps côté code.
    Surtout qu''en PHP, il y a ce qu'il faut en fonctionnalités.

    Comme je m'y connais la dessus (je suis ces histoires de près !), je me permets d'intervenir. Effectivement, le SGBD n'est pas la source de la faille. Mais la faille est une conséquence du manque de fonctionnalités du SGBD choisi.
    En quoi laisser l'accès à des données d'un utilisateur lambda depuis un autre utilisateur via une URL est une conséquence d'un manque de fonctionnalité du SGBD ? Là je ne comprend pas.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur le P2V, mon article sur le cloud
    Consultez nos FAQ : Windows, Linux, Virtualisation
      8  0

  3. #23
    Membre du Club
    Homme Profil pro
    Développeur Back-End
    Inscrit en
    novembre 2012
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Développeur Back-End
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : novembre 2012
    Messages : 13
    Points : 58
    Points
    58
    Par défaut
    Citation Envoyé par chrtophe Voir le message
    Surtout qu''en PHP, il y a ce qu'il faut en fonctionnalités.
    En PHP, ou autres techno, il y a largement ce qu'il faut. Comme la libraire Sodium/Argon2i etc...
    bref
      1  0

  4. #24
    Membre habitué
    Homme Profil pro
    WANT
    Inscrit en
    juin 2011
    Messages
    40
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Finlande

    Informations professionnelles :
    Activité : WANT

    Informations forums :
    Inscription : juin 2011
    Messages : 40
    Points : 140
    Points
    140
    Par défaut
    Haha le sujet bien troll.

    tout d’abord je ne comprends pas très bien ce que viennent faire des phrases comme :

    Pour cela les grands éditeurs (Oracle, Microsoft SQL Server) proposent une méthode globale appelée TDE (Transparent Data Encryption) pour chiffrer de manière élégante et sans impact sur les performances relationnelles, la totalité des données de la base. Cette technologie est hors de portée du monde libre.

    Pourquoi cette technologie est hors de portée du monde libre ?

    De plus même si je vois tout a fait et comprend les points mis en avant il serait

    1 juste de remettre dans le contexte économico-temporel (comme exprimé par d’autre)
    2 bien plus utile de rédiger ces griefs/problèmes dans un courriel en anglais a destination des mailings list des dits sgbd.

    Et dans un monde de plus en plus pauvre et régit par la «*loi*» du marché il ne faut pas s’étonner de voir les gens/sociétés fuir les gros éditeurs qui malgré tout se gavent bien et détournent des fonds a tour de bras.

    Il est question de chiffrement, donc de sécurité, donc de confiance.
    Je suis désolé de dire que je ne fais pas confiance a Microsoft ni au logiciel propriétaire.

    - Microsoft car l’état américain se sert d’eux dans sa guéguerre puérile de la conquête du monde. Notamment pour couler/faire pression sur les concurrents etc (voir publication des journalistes et des lanceurs d’alertes) on peut parler des cloud act, etc.
    - Factuellement on ne sait pas facilement ce que les logiciels propriétaires font de nos données et il est difficile (impossible) pour le développeur lambda de pouvoir auditer le code. (vous avez dit rgpd)

    C’est un risque que je déconseille de prendre a des sociétés qui souhaitent survivre, lancer des produits a l’international ou se mettre sur un secteur ou il existe des sociétés américaines.

    Comme a mon habitude plein de fautes, je m’en excuse.
      5  2

  5. #25
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2014
    Messages
    87
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : octobre 2014
    Messages : 87
    Points : 83
    Points
    83
    Par défaut GROUP BY
    MySQL/MariaDB a la fâcheuse tendance à renvoyer n’importe quoi sans jamais émettre d’erreur dans le cas où la clause GROUP BY est incomplète, donnant des résultats hasardeux presque toujours faux !
    Avec MariaDB 10.3 (et il me semble que déjà avec quelques sous-versions/versions en dessous aussi), on n'a pas ce problème.

    On a une erreur de ce style : Syntax error or access violation: 1055 '{DB_NAME}.{TABLE-NAME}.{COLUMN_NAME}' isn't in GROUP BY
      4  0

  6. #26
    Inactif  

    Profil pro
    Inscrit en
    janvier 2011
    Messages
    3 064
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : janvier 2011
    Messages : 3 064
    Points : 4 377
    Points
    4 377
    Par défaut
    Bonjour,

    Dans les truc farfelus de mysql j'ai trouvé ceci :

    Créez une table ou vous injectez automatiquement de la data. Votre clef est un autoincremente. L'autoincremente a une gestion désastreuse des numéros ... Vous insérez 10000 lignes , votre compteur passe de 5000 à 7000 sans raison vous arrivez donc à 12000 .

    Vous pensez au final avoir 12000 , erreur ! Vous en avez bien 10000 ... Pourquoi un tel comportement ? L'autoincremente n'est pas au point.

    C'est dangereux car le compteur de l'incremente est "trompeur" . Se retrouver avec des "trou" dans une numérotation censé être logique est assez ubuesque pour un SGBD ...
      1  5

  7. #27
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2014
    Messages
    87
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : octobre 2014
    Messages : 87
    Points : 83
    Points
    83
    Par défaut
    Citation Envoyé par tanaka59 Voir le message
    C'est dangereux car le compteur de l'incremente est "trompeur" . Se retrouver avec des "trou" dans une numérotation censé être logique est assez ubuesque pour un SGBD ...
    C'est vrai que l'auto-incrémentation de MySQL (et aussi de MariaDB 10.3) peut de temps à autre être trompeur.

    C'est pour cette raison qu'il ne faut jamais utiliser l'id pour les numérotations de facture.
    Je m'explique :
    Imaginons qu’on utilise MySQL ou MariaDB et qu’on utilise les transaction, et qu’un membre valide une commande et que la transaction échoue pour lui, et que juste après un autre membre valide sa commande et qu’avec lui la transaction n’échoue pas : le résultat est qu’on aura un trou dans le numérotation (exemple : l’id passera de 100 à 102, la facture numéro 101 sera donc manquante, et en France on a pas le droit d’avoir de trou dans la numérotation de factures).

    Et même pour toute autre numérotation je déconseille d'utiliser l'id (numéro de devis, numéro clients, numéro des SAV, etc.).

    Pour détourner ce "problème", pour résumé je fais ceci :
    Perso j'utiliser une table spécialement créée pour les systèmes de compteur. Et dans cette table j'ai une ligne pour chaque module pour lesquels j'ai besoin d'un compteur (sans trou). Et pour les tables des modules dans lesquels je veux un système de compteur (sans trou) j'ajoute une colonne integer spécialement pour indiquer le numéro de la ligne.
    Et lorsque je fait un INSERT d'une nouvelle ligne (d'une nouvelle facture par exemple) : j'ouvre abord une transaction et je fait un SELECT ... FOR UPDATE, et ensuite je fait mon INSERT + j'incrémente la compteur (dans la table créée spécialement pour) + éventuellement quelques autres req SQL avant de valider la transaction.
      6  0

  8. #28
    Responsable Systèmes


    Homme Profil pro
    Technicien maintenance
    Inscrit en
    août 2011
    Messages
    14 995
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : août 2011
    Messages : 14 995
    Points : 34 818
    Points
    34 818
    Par défaut
    Pour cela les grands éditeurs (Oracle, Microsoft SQL Server) proposent une méthode globale appelée TDE (Transparent Data Encryption) pour chiffrer de manière élégante et sans impact sur les performances relationnelles, la totalité des données de la base. Cette technologie est hors de portée du monde libre.
    Le TDE est disponible sur la version commerciale de MySQL.
    Ca semble disponible aussi avec MariaDB.
    Je n'ai pas la compétence pour juger ce que ça vaut par rapport à Oracle ou SQL Server.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur le P2V, mon article sur le cloud
    Consultez nos FAQ : Windows, Linux, Virtualisation
      4  0

  9. #29
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 019
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 8 019
    Points : 28 212
    Points
    28 212
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Xurudragon Voir le message
    Pour moi, MySQL/MariaDB est/sont l'un des SGBD qui évolue le plus rapidement.
    Je pense qu'il convient de rappeler que MySQL / MariaDB viennent à peine d'intégrer les CTE et autres apports de la norme SQL de ... 1999 soit avec presque 20 ans de retard ! Ils ont fait à peine mieux concernant les fonctions fenêtrées puisque ca n'a pris que ... 10 ans EDIT 15 ans puisque les fonctions fenêtrées sont un apport de la version SQL 2003
      2  0

  10. #30
    Membre du Club
    Homme Profil pro
    Développeur Back-End
    Inscrit en
    novembre 2012
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Développeur Back-End
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : novembre 2012
    Messages : 13
    Points : 58
    Points
    58
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Je pense qu'il convient de rappeler que MySQL / MariaDB viennent à peine d'intégrer les CTE et autres apports de la norme SQL de ... 1999 soit avec presque 20 ans de retard ! Ils ont fait à peine mieux concernant les fonctions fenêtrées puisque ca n'a pris que ... 10 ans
    Certes mais qui utilise réellement toutes ces fonctionnalités de la norme SQL ? d'ailleurs on en parle niveau normalisation des différences de syntaxe entre tous les SGBD ?

    En général on lui demande d'être relativement performant, simple à utiliser et à configurer.
    Quand au reste c'est du plus spécifique et totalement faisable (clusterisation etc... mais là, tout comme pour les autres SGBD, ça se complexifie forcément)
      3  4

  11. #31
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 019
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 8 019
    Points : 28 212
    Points
    28 212
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par stephweb Voir le message
    C'est vrai que l'auto-incrémentation de MySQL (et aussi de MariaDB 10.3) peut de temps à autre être trompeur.

    C'est pour cette raison qu'il ne faut jamais utiliser l'id pour les numérotations de facture.
    Je m'explique :
    Imaginons qu’on utilise MySQL ou MariaDB et qu’on utilise les transaction, et qu’un membre valide une commande et que la transaction échoue pour lui, et que juste après un autre membre valide sa commande et qu’avec lui la transaction n’échoue pas : le résultat est qu’on aura un trou dans le numérotation (exemple : l’id passera de 100 à 102, la facture numéro 101 sera donc manquante, et en France on a pas le droit d’avoir de trou dans la numérotation de factures).

    Et même pour toute autre numérotation je déconseille d'utiliser l'id (numéro de devis, numéro clients, numéro des SAV, etc.).

    Pour détourner ce "problème", pour résumé je fais ceci :
    Perso j'utiliser une table spécialement créée pour les systèmes de compteur. Et dans cette table j'ai une ligne pour chaque module pour lesquels j'ai besoin d'un compteur (sans trou). Et pour les tables des modules dans lesquels je veux un système de compteur (sans trou) j'ajoute une colonne integer spécialement pour indiquer le numéro de la ligne.
    Et lorsque je fait un INSERT d'une nouvelle ligne (d'une nouvelle facture par exemple) : j'ouvre abord une transaction et je fait un SELECT ... FOR UPDATE, et ensuite je fait mon INSERT + j'incrémente la compteur (dans la table créée spécialement pour) + éventuellement quelques autres req SQL avant de valider la transaction.
    Les trous de numérotation des ID calculés par le SGBD (auto_incrément pour MySQL, sequence ou identity column dans d'autres SGBD) ne sont pas une spécificité de MySQL.
    Quelque soit le SGBD, il ne faut jamais utiliser un identifiant attribué par le SGBD comme identifiant fonctionnel, ni pour numéroter des factures ni pour quelque autre usage que ce soit.
    Pour rappel, ces identifiants techniques peuvent non seulement comporter des trous, mais également ne pas être commités chronologiquement
    Il est tout à fait possible, tout à fait normal et même relativement fréquent, surtout en environnement multi-threads fortement concurrentiel, que l'identifiant n°105 soit enregistré avant l'identifiant n° 100 par exemple
      10  0

  12. #32
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2014
    Messages
    87
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : octobre 2014
    Messages : 87
    Points : 83
    Points
    83
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Les trous de numérotation des ID calculés par le SGBD (auto_incrément pour MySQL, sequence ou identity column dans d'autres SGBD) ne sont pas une spécificité de MySQL.
    Quelque soit le SGBD, il ne faut jamais utiliser un identifiant attribué par le SGBD comme identifiant fonctionnel, ni pour numéroter des factures ni pour quelque autre usage que ce soit.
    Pour rappel, ces identifiants techniques peuvent non seulement comporter des trous, mais également ne pas être commités chronologiquement
    Il est tout à fait possible, tout à fait normal et même relativement fréquent, surtout en environnement multi-threads fortement concurrentiel, que l'identifiant n°105 soit enregistré avant l'identifiant n° 100 par exemple
    Yes.
    Mais beaucoup de dév utilisent les id pour les numérotations de factures.
      1  0

  13. #33
    Membre du Club
    Homme Profil pro
    Développeur Back-End
    Inscrit en
    novembre 2012
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Développeur Back-End
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : novembre 2012
    Messages : 13
    Points : 58
    Points
    58
    Par défaut
    Citation Envoyé par stephweb Voir le message
    Yes.
    Mais beaucoup de dév utilisent les id pour les numérotations de factures.
    Mais là ce n'est, encore une fois, pas un problème de SGBD, mais un problème de connaissance du/des développeurs
      8  0

  14. #34
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 019
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 8 019
    Points : 28 212
    Points
    28 212
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Xurudragon Voir le message
    Certes mais qui utilise réellement toutes ces fonctionnalités de la norme SQL ? d'ailleurs on en parle niveau normalisation des différences de syntaxe entre tous les SGBD ?

    En général on lui demande d'être relativement performant, simple à utiliser et à configurer.
    Quand au reste c'est du plus spécifique et totalement faisable (clusterisation etc... mais là, tout comme pour les autres SGBD, ça se complexifie forcément)
    Les CTE sont un apport énorme dont l'usage est quasi quotidien, sans parler des requêtes récursives, d'usage certes moins fréquent, mais qui ne peuvent fonctionner qu'avec les CTE

    Les fonctions fenêtrées sont également extrêmement utiles dans bien des cas et permettent parfois des solutions plus performantes que sans fonction fenêtrées (mesures à l'appui).

    Mais je voulais surtout relever que votre affirmation
    Pour moi, MySQL/MariaDB est/sont l'un des SGBD qui évoluent le plus rapidement.
    est une contre-vérité : respectivement 20 ans et 15 ans pour suivre les évolutions, c'est gigantesque !

    PS : j'en profite pour corriger en vert votre citation, on ne se refait pas, le sujet de "évoluent" est "les SGBD"
      7  1

  15. #35
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    2 652
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 2 652
    Points : 10 390
    Points
    10 390
    Billets dans le blog
    21
    Par défaut
    Citation Envoyé par chrtophe Voir le message
    En quoi laisser l'accès à des données d'un utilisateur lambda depuis un autre utilisateur via une URL est une conséquence d'un manque de fonctionnalité du SGBD ? Là je ne comprend pas.
    Si tu ne stockes pas tes données dans une BD, tu les stockes très certaines dans un fichier. Fichier qui se trouve dans un répertoire. Fichier qui, par fainéantise, est accessible directement par une URL (mettons "http://monsitepassur.org/fichiers/carte_vital.pdf", en HTTP histoire d'enfoncer le clou ).

    Quand tu es une quiche en configuration Apache (ou Nginx ou autres hein !), le dossier est "navigable" depuis n'importe quel navigateur. Et donc, en ayant l'URL d'un fichier, si on retire juste le fichier et que l'on saisie "http://monsitepassur.org/fichiers", tu vas avoir l'intégralité des fichiers présents dans le répertoire.

    Quand tu stockes toutes tes données en BD (les fichiers y compris donc), cette situation n'est pas possible, sauf à le vouloir volontairement.
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels
      2  5

  16. #36
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2014
    Messages
    87
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : octobre 2014
    Messages : 87
    Points : 83
    Points
    83
    Par défaut
    Citation Envoyé par François DORIN Voir le message
    Si tu ne stockes pas tes données dans une BD, tu les stockes très certaines dans un fichier. Fichier qui se trouve dans un répertoire. Fichier qui, par fainéantise, est accessible directement par une URL (mettons "http://monsitepassur.org/fichiers/carte_vital.pdf", en HTTP histoire d'enfoncer le clou ).

    Quand tu es une quiche en configuration Apache (ou Nginx ou autres hein !), le dossier est "navigable" depuis n'importe quel navigateur. Et donc, en ayant l'URL d'un fichier, si on retire juste le fichier et que l'on saisie "http://monsitepassur.org/fichiers", tu vas avoir l'intégralité des fichiers présents dans le répertoire.

    Quand tu stockes toutes tes données en BD (les fichiers y compris donc), cette situation n'est pas possible, sauf à le vouloir volontairement.
    Les fichiers sensibles, il ne faut certainement pas qu'ils soient accessibles via l'URL par tout le monde, il ne faut donc pas les mettre dans un répertoire public.
    Si on ne veut pas les mettre en BDD, il faut les mettre dans un répertoire de storage qui n'est pas accessible par tout le monde via l'URL.
    Et lorsqu'un utilisateur loggé (qui a les droits d'accès) veut voir le fichier via l'URL, on charge le fichier en PHP (en vérifiant les droits de l'utilisateur juste avant).
      7  0

  17. #37
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    2 652
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 2 652
    Points : 10 390
    Points
    10 390
    Billets dans le blog
    21
    Par défaut
    Citation Envoyé par stephweb Voir le message
    Les fichiers sensibles, il ne faut certainement pas qu'ils soient accessibles via l'URL par tout le monde, il ne faut donc pas les mettre dans un répertoire public.
    Si tu suis bien la conversation, ce n'est pas moi qu'il faut convaincre Ce n'était qu'un exemple.

    Mais je vois tellement ça dans mon boulot.... Et la CNIL aussi semble-t-il ! Y compris dans des projets réalisés par de grandes ESN...
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels
      1  0

  18. #38
    Responsable Systèmes


    Homme Profil pro
    Technicien maintenance
    Inscrit en
    août 2011
    Messages
    14 995
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : août 2011
    Messages : 14 995
    Points : 34 818
    Points
    34 818
    Par défaut
    @François, ok je comprend mieux ce que tu voulais dire.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur le P2V, mon article sur le cloud
    Consultez nos FAQ : Windows, Linux, Virtualisation
      1  0

  19. #39
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    juillet 2019
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : juillet 2019
    Messages : 3
    Points : 0
    Points
    0
    Par défaut
    J'aurai quand même toujours plus confiance en un logiciel libre qu'en n'importe quelle boîte noire propriétaire. Je peux maintenir le code et je sais ce qu'il s'y passe.

    C'est simplement indispensable. A partir de là, les SGDB proprios sont nécessairement mauvais et dangereux selon moi, peu importe leurs qualités intrinsèques.
      4  11

  20. #40
    Membre du Club
    Homme Profil pro
    Cloud Architect
    Inscrit en
    mars 2016
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Cloud Architect

    Informations forums :
    Inscription : mars 2016
    Messages : 11
    Points : 56
    Points
    56
    Par défaut
    Malgré des vérités, l'article ne paraît pas vraiment neutre:

    1- Sur la disparition des tables, j'ai envie de dire que qui touche à des fichiers sur son disque, s'expose à des ennuis. (ça ne m'étonnerait pas que quelqu'un parvienne à altérer davantage un fichier catalogue pour faire mentir une base SQL Server ou autre, comme l'on peut altérer le mapping XML d'un Excel .xlsx ou ses données et paramètres en l'ouvrant comme un Zip et en altérant les fichiers .xml qui le compose).

    2- Sur la validation des transactions, il est vrai que je ne fais aucune confiance à un ROLLBACK. Cela dit, il existe des alternatives bien plus safe dans un contexte de simulation comme utiliser des tables temporaires imitant une table différente (en la créant LIKE la table voulu, ...), ou même en jouant avec des partitions. (Utiliser une table identique non partitionné, jouer avec et requêter dessus pour la simulation, utiliser la feature ALTER TABLE ... EXCHANGE PARTITION au moment où l'on veux la figer dans la table définitive partitionné, sans aucun temps de latence due à cette action). (Bon j'accorderais qu'il est possible de faire mentir ENCORE PLUS MySQL avec la logique des partitions... Mais quand on sait bien l'exploiter, il y a des usages très intéressants je trouve).

    3- schema vs database, c'est un peu faire un procès aux abus de langage pour une feature non supporté mais accepté au nom de l'interopérabilité du code SQL. Comme on ne peut pas faire d'index DESC, ou que certains keywords sont sans effets pour MySQL malgré qu'il les acceptes.

    4- Pour les statistiques fausses, je considère qu'il est la responsabilité du développeur de se rendre compte du résultat de ce qu'il a exécuté comme requête, et de la cohérence des données. Alors oui MySQL pourrait faire "met tout en group by !!!", mais maintenant, avouons que si j'écris:
    SELECT A, B, SUM(C) FROM X WHERE B = 1 GROUP BY A;
    Il semble peu utile d'avoir à group by A,B ou d'avoir à faire un MAX(B) dans l'unique but de satisfaire le SGBD (chose qui serait réclamer par d'autres SGBD).
    C'est une histoire de comportement plus ou moins strict, mais je pense que le développeur faisant un GROUP BY n'est pas censé le faire pour décoré et doit savoir ce qu'il fait et ce que fait la technologie qu'il utilise. Si les données lui mente, à lui d'être rigoureux et de group by correctement.
    De plus il y a la configuration "ONLY_FULL_GROUP_BY" qui peut être ajouté, pour rendre MySQL plus strict.

    5- Comme déjà mentionné pour la sauvegarde, la solution de Percona XtraBackup fait l'affaire et gratuitement.

    6- Défense du libre, en-dehors d'avoir à trainer les faibles priorités de la part de Oracle & co (car ils faut bien vendre des versions payante ou privilégié les bdd Oracle de la maison...), elles ont permis la naissance du fork MariaDb (qui n'est pas que décoratif et apporte des lots d'optimisation et d'amélioration en terme de sécurité entre autre, ... Et dispose également d'un bon moteur de performance au delà du InnoDB), des solutions de Percona (mieux optimisé et avec de bons outils), des forks RDS Aurora par Amazon (qui a ses solutions de sécurité, de sauvegarde, de ses optimisations maisons, ses tricks permettant sous conditions de faire des alter table instantané pour des ajouts de colonnes... Et une intégration très avancé avec leur service S3 s'hybridant à l'import/export avec des fichiers CSV (load from / into outfile), et même des lambdas (permettant d'exécuter du code dans n'importe quel langage aujourd'hui, de façon synchrone ou asynchrone, pour notifier d'une action ou recevoir une information extérieur dans un process à l'intérieur de la base de données) et enfin de supporter mieux des bases de données de plus de 1To).


    Je trouve que l'article charge un peu trop MySQL, sans chercher à être toujours 100% objectif.
      7  2

Discussions similaires

  1. Réponses: 0
    Dernier message: 11/04/2017, 21h02
  2. Réponses: 3
    Dernier message: 27/09/2016, 15h00
  3. RHEL 7 supportera MariaDB par défaut à la place de MySQL
    Par Stéphane le calme dans le forum Actualités
    Réponses: 4
    Dernier message: 28/07/2013, 12h30
  4. Réponses: 16
    Dernier message: 31/03/2011, 14h36

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo