Je lis / regarde beaucoup de contenu de Robert C. Martin. Je l'ai rencontré en train de dire que SQL n'était pas nécessaire à cause des disques SSD. Lorsque je recherche d'autres sources pour sauvegarder cela, je reçois une série d'articles aléatoires décrivant la différence de performances SQL entre les disques durs et les disques SSD (ce qui est lié mais pas ce que j'essaie de rechercher).

En fin de compte, je ne comprends pas à quoi il veut en venir. Est-il en train de dire de remplacer SQL par les technologies No-SQL? Est-il en train de dire de stocker des données dans des fichiers dans un système de fichiers? Ou veut-il simplement que les gens arrêtent d'utiliser SQL / Relational Databases en raison d'attaques SQLi? Je crains de ne pas comprendre ce qu'il essaie de dire.

Je vais fournir quelques liens ici pour que vous puissiez lire directement dans son esprit:

1. Tables Bobby
2. Conférence sur l'architecture propre

Premièrement, il déclare que SQL devrait être entièrement supprimé du système.

La solution. La seule solution. C’est éliminer complètement le code SQL du système. S'il n'y a pas de moteur SQL, il ne peut y avoir d'attaques SQLi.

Et bien qu'il parle de remplacer SQL par une API, je ne pense pas qu'il veuille dire mettre SQL derrière une API à cause de cette citation précédente et de ce qu'il a dit plus tôt dans l'article.

Les frameworks ne traitent pas le problème; ...

Note latérale: En disant SQL, je suis presque certain que Robert veut dire la plupart des bases de données relationnelles. Peut-être pas tout sauf la plupart. Dans tous les cas, la plupart des gens utilisent quand même SQL. alors...

Si SQL n'est pas utilisé pour conserver des données, que devons-nous utiliser?

Avant de répondre à cela, je devrais également noter. Robert souligne que les disques SSD devraient changer les outils que nous utilisons pour conserver les données. La réponse de Søren D. Ptæus le souligne.

Je dois également répondre au groupe "mais intégrité des données". Après quelques recherches, Robert recommande d' utiliser des bases de données transactionnelles telles que datomic . Puis CRUD se transforme en CR (créer et lire) et les transactions SQL disparaissent complètement. L'intégrité des données est bien sûr importante.

Je ne peux pas trouver une question qui englobe tout cela. Je suppose que je cherche des alternatives qui correspondent aux directives de Robert. Datomic en est un, mais est-ce cela? Quelles autres options correspondent à ces directives? Et fonctionnent-ils réellement mieux avec les disques SSD?

Bob Martin exagère clairement pour clarifier son propos. Mais quel est son point?

Veut-il simplement que les gens arrêtent d'utiliser SQL / Bases de données relationnelles à cause d'attaques SQLi?

À ce que je sache, dans cet article de blog (votre premier lien), Martin tente de convaincre les gens d'arrêter d'utiliser SQL, mais pas les bases de données relationnelles. Ce sont deux choses différentes .

SQL est un langage extrêmement puissant et standardisé dans une certaine mesure. Il permet de créer des requêtes et des commandes complexes de manière très compacte, de manière lisible, compréhensible et facile à apprendre. Il ne dépend pas d'un autre langage de programmation, il est donc utilisable par la plupart des programmeurs d'applications, qu'ils préfèrent Java, C, C ++, C #, Python, Ruby, JavaScript, Basique, Go, Perl, PHP ou autre chose.

Cependant, ce pouvoir a un coût : écrire des requêtes / commandes SQL sécurisées est plus difficile que d’écrire des requêtes / commandes non sécurisées. Une API sécurisée devrait faciliter la création de requêtes sécurisées "par défaut". Les personnes potentiellement dangereuses devraient avoir besoin de plus d'efforts mentaux ou du moins de dactylographie. C’est pourquoi, à mon humble avis, Martin s’oppose à SQL sous sa forme actuelle.

Le problème n'est pas nouveau et il existe des API plus sûres que le SQL standard pour accéder à une base de données relationnelle. Par exemple, tous les mappeurs OR que je connais essaient de fournir une telle API (bien qu’ils soient généralement conçus pour d’autres objectifs principaux). Les variantes SQL statiques rendent difficile la création de requêtes dynamiques avec des données d'entrée non authentifiées (et il ne s'agit pas d'une nouvelle invention: le SQL incorporé, qui utilise souvent du SQL statique, date d'environ 30 ans).

Malheureusement, je ne connais aucune API aussi souple, standardisée, mature, indépendante du langage et aussi puissante que SQL, en particulier le SQL dynamique. C'est pourquoi j'ai des doutes sur la suggestion de Martin de "ne pas utiliser SQL" comme moyen réaliste de résoudre les problèmes mentionnés. Alors lisez son article comme une pensée allant dans la bonne direction, et non comme une "pratique exemplaire" que vous pourrez suivre aveuglément à partir de demain.

L’opinion de Bob Martin n’est que cela; l'opinion d'un homme.

Un programmeur est censé comprendre le système qu’il écrit assez bien pour prendre des mesures raisonnables pour assurer sa sécurité et ses performances. Cela signifie que si vous parlez à une base de données SQL, vous faites ce que le site Web de Bobby Tables dit: vous désinfectez vos données d'entrée. Cela signifie que vous placez votre base de données SQL sur une machine offrant des performances suffisantes. Il existe des moyens très connus et bien compris de faire ces choses, et bien qu'ils ne garantissent pas une sécurité absolue ni des performances optimales, rien d'autre ne le fait.

L'affirmation selon laquelle nous n'avons plus besoin de SQL, car nous disposons maintenant de disques SSD, est simplement spécieuse. SQL n'a pas été inventé car les disques durs à grande vitesse n'existaient pas encore; il a été inventé parce que nous avions besoin d'un moyen standard de l'industrie pour exprimer les concepts de récupération de données. Outre la rapidité et la sécurité, les systèmes de bases de données relationnelles présentent de nombreuses autres qualités qui les rendent idéales pour les opérations commerciales; en particulier, ACID . L'intégrité des données est au moins aussi importante que la rapidité ou la sécurité. Si vous ne l'avez pas encore, à quoi sert-il de sécuriser les mauvaises données ou de les récupérer le plus rapidement possible?

Avant de prendre l'hystérie d'un homme comme évangile, je vous suggère d'en apprendre davantage sur la sécurité et les performances des applications et des systèmes, à leur manière, et non en lisant des articles Internet aléatoires. La sécurité, les performances et la conception de systèmes robustes vont bien au-delà de la simple "éviter cette technologie".

Nous n'interdisons pas les couteaux de cuisine car quelques personnes malchanceuses réussissent à se couper les doigts par accident.

Qu'est-ce qu'il dit réellement?

Est-il en train de dire de remplacer SQL par les technologies No-SQL?

TL; DR: oui (en quelque sorte)

Dans une conversation plus récente que celle à laquelle vous vous êtes lié, il a déclaré: "La base de données est un détail. Pourquoi avons-nous des bases de données?" .

Il affirme que la base de données a été créée pour faciliter l'accès aux données à partir de disques en rotation, mais qu'à l'avenir, "[...] il n'y aura pas de disques" grâce à la nouvelle technologie et à ce qu'il appelle "une mémoire vive persistante" et qu'il sera plus facile de stocker des données en utilisant les structures utilisées par les programmeurs, telles que les tables de hachage ou les arbres.

Il poursuit en prédisant que les bases de données relationnelles dans un ensemble vont en grande partie disparaître en raison de leur nouvelle concurrence:

Si j'étais Oracle, j'aurais très peur parce que la raison de mon existence est en train de s'évaporer sous moi. [...] La raison de l'existence de la base de données est en train de disparaître.

Il y aura probablement des tables relationnelles qui survivront, mais maintenant, il y a une concurrence saine .

Donc non, pour lui, il ne s'agit pas uniquement d'injection SQL, même s'il est d'avis que SQL est fondamentalement défectueux à cet égard .

Note de l'auteur:

Les déclarations contenues dans ce message ne sont que des citations pour comprendre le point de vue de Robert C. Martin sur ce sujet et ne représentent pas l'opinion de l'auteur. Pour un point de vue plus différencié, voir la réponse de Robert Harvey .

SQL est un détail. La connaissance d'un détail ne devrait pas se propager.

Comme SQL est utilisé dans de plus en plus d'endroits dans votre code, votre code en devient de plus en plus dépendant.

Au fur et à mesure que vous apprenez de plus en plus d’astuces SQL, vous résolvez de plus en plus de problèmes à l’aide de SQL. Cela signifie que le passage à une autre API pour persister implique plus que la simple traduction. Vous devez résoudre des problèmes que vous n'aviez pas compris.

Vous rencontrez cette même basculement entre les bases de données. L'un d'eux propose la fonctionnalité 5 fantaisie whizzbang, vous ne l'utilisez donc que dans un certain nombre d'endroits pour découvrir que la fonctionnalité 5 fantaisie de whizzbang est exclusive. Vous avez maintenant un problème de licence qui va coûter très cher. Vous avez donc beaucoup de travail à creuser partout où vous avez utilisé la fonctionnalité 5 et à résoudre le problème vous-même, pour découvrir plus tard que vous utilisez également la fonctionnalité whizzbang 3.

Une des choses qui rend Java si portable est que certaines fonctionnalités du processeur ne sont tout simplement pas disponibles. S'ils étaient disponibles, je les utiliserais. Et tout à coup, il y a des processeurs sur lesquels mon code Java ne fonctionnera pas car ils ne possèdent pas ces fonctionnalités. C'est la même chose avec les fonctionnalités de base de données.

C’est trop facile de sacrifier son indépendance sans s’en rendre compte. SQL est un choix pas une donnée. Si vous décidez d'utiliser SQL, placez-le à un endroit. Faites-le d'une manière qui peut être défaite.

Le fait que SQL pose des problèmes de sécurité et que nous passions à des modèles de mémoire persistante ne signifie pas que SQL est condamné. Cela fait bien comprendre que c'est un choix. Si vous voulez conserver le droit de faire ce choix, vous devez faire le travail.

Il convient de noter que le mouvement de la base de données des années 80 et de l’oncle Bob a une histoire plutôt désagréable. Il a eu tous ses problèmes résolus avec un système de fichiers à plat lorsque la direction a forcé un administrateur de base de données à entrer dans sa vie. Cet événement l'a poussé dans sa carrière de consultant. (Il raconte cette histoire dans l'un de ses premiers livres épurés, oubliez lequel) Il sait comment résoudre les problèmes sans DB et a peu de patience pour ceux qui agissent comme si les utiliser était une donnée.

Il raconte également comment reporter l’ajout d’une base de données à une application jusqu’à la dernière minute, lorsqu'un client l’a demandé, et l’a ajouté en une journée, en tant que fonctionnalité facultative. À mon avis, il voit la façon dont la plupart d'entre nous utilisons DB comme une dépendance. Il essaie de nous montrer comment éliminer l'habitude.

La citation de votre première citation est (souligné par moi),

La solution. La seule solution. C’est éliminer complètement le SQL du système . S'il n'y a pas de moteur SQL, il ne peut y avoir d'attaques SQLi.

Qu'est-ce qui remplacerait SQL? Une API bien sûr! Et PAS une API qui utilise un langage textuel. À la place, une API qui utilise un ensemble approprié de structures de données et d’appels de fonction pour accéder aux données nécessaires.

Ce discours est contre le fait de laisser les programmeurs d’applications utiliser SQL.

Le correctif suggéré est de les laisser utiliser une API à la place: ce qui n'est pas du SQL et ne permet pas l'injection.

OMI, des exemples de telles API peuvent inclure:

• http://bobby-tables.com/csharp suggère aux programmeurs C # d'utiliser l'API ADO.NET.

  Ce n’est pas un exemple parfait, car ADO.NET est une API large ou profonde (c’est-à-dire puissante ou polyvalente), qui permet également à ses utilisateurs de saisir du SQL brut (ou brut).

• Certains développeurs SQL ou administrateurs de bases de données suggèrent qu'une base de données soit configurée de telle sorte qu'elle n'autorise l'accès que via des procédures stockées ( rédigées de manière experte) et que les développeurs d'applications ne soient pas autorisés à écrire leurs propres requêtes SQL (dangereuses).

• Un autre moyen "d'éliminer le code SQL du système" consiste à placer la base de données (qui expose le code SQL) sur un autre système, accessible via une API REST ou similaire.

Ainsi, IMO, la solution globale ou les systèmes peuvent toujours utiliser une base de données (d’autant plus qu’un moteur de base de données implémente des propriétés ACID utiles et qu’il s’adapte bien, etc. spécifique à une application).

Les exigences du client sont satisfaites si l'API SQL de la base de données est cachée des développeurs d'applications, derrière une autre API (par exemple, ADO, peut-être un ORM, un service Web, etc.).

Plus généralement, je suppose que cela signifie avoir un DAL spécifique à l'application (une "couche d'accès aux données" ou "couche d'abstraction de base de données"). Un DAL isole l'application des détails de comment et où les données sont stockées et / ou récupérées. Le DAL peut ou non être implémenté à l'aide d'une base de données SQL.

Tout le monde semble répondre à cette question du point de vue de la sécurité ou avec une optique SQL.

J'ai assisté à une conférence de Robert Martin dans laquelle il raconte qu'en tant que programmeurs, nous utilisons différentes structures de données optimales pour nos programmes spécifiques. Ainsi, plutôt que de stocker universellement toutes les données dans une structure tabulaire, nous devrions stocker nos données dans des tables de hachage, des arborescences, etc. afin que nous puissions récupérer les données et accéder directement au programme.

J’ai interprété son message comme une simple affirmation: nous devrions rejeter un instant nos hypothèses sur le stockage persistant pour envisager d’autres possibilités que le vieux format tabulaire SQL. Le SSD est une solution candidate, mais pas la seule.

En fait, il ne doit pas utiliser les bases de données et SQL - de manière assez explicite. La première référence est une question bien connue, la deuxième référence sonnera comme un coup de gueule. Bien que, je l’interprète comme une bonne raison d’utiliser des bases de données et de ne pas utiliser SQL. De mon point de vue, ce n'est même pas un conseil raisonnable.

Malheureusement, l'exemple qu'il utilise est un exemple bien connu avec une solution bien connue qu'il souligne ensuite. Cela se produit généralement lorsqu'un programmeur ne réalise pas ce qu'il fait. Par exemple, construire des chaînes contenant du SQL comme:

    my $sql="select a from b where a=$ui_val;";
    prepare($sql)
    execute($sql)

par opposition à

    my $sql="select a from b where a=?;";
    prepare($sql)
    execute($sql,$ui_val);

C'est un exemple comme DBI perl pour le code ruby ​​on rails. Le code de rails qu'il fournit est facile à confondre entre le sûr et le non sécurisé. Comme beaucoup d'ORM, cache le SQL sous-jacent et vous avez souvent affaire à une interface qui construit et exécute le SQL pour vous. Cela ne ressemble-t-il pas à ce qu'une API ferait pour vous?

Mon interprétation de la première référence est qu'il suggère de remplacer un problème bien connu pour lequel une solution est bien connue.

Il est également regrettable qu’il ne mentionne pas que, si cela est fait correctement, le code sera plus facile à écrire et plus lisible, bien que, s’il est bien fait, il sera peut-être plus difficile à écrire et moins lisible. De plus, il ne mentionne pas que SQL est vraiment très facile à lire et fait ce que vous attendez généralement de lui.

Il est partiellement correct, nous aurons finalement une mémoire infiniment grande et rapide et un processeur infiniment rapide. Jusqu'à ce que nous nous échappions de la physique actuelle qui contraint l'informatique, il n'a pas raison.

Oui, les disques en rotation appartiennent au passé et nous utilisons maintenant des disques SSD. Les disques fonctionnent avec environ 10 millisecondes par transfert de données, les disques SSD avec un temps d'accès aux données d'environ 0,5 millisecondes (500 microsecondes). La RAM est de l’ordre de 100 nanosecondes, les processeurs fonctionnent à une centaine de secondes. C'est pourquoi nous avons besoin de bases de données. Les bases de données gèrent le transfert de données entre des disques en rotation ou des disques SSD dotés de la mémoire principale. L'avènement des disques SSD n'a pas éliminé le besoin de bases de données.

Répondre

veut-il simplement que les gens arrêtent d'utiliser SQL / Bases de données relationnelles à cause d'attaques SQLi?

L'article de 'Bobby Tables' semble suggérer que ceci, en soi, est une raison de ne pas utiliser SQL:

La solution. La seule solution. C’est éliminer complètement le code SQL du système. S'il n'y a pas de moteur SQL, il ne peut y avoir d'attaques SQLi.

Il pourrait avoir d'autres raisons dont il discute ailleurs. Je ne saurais pas parce que je ne lis pas beaucoup de choses sur lui.

Digression

Cette partie n’est pas vraiment une réponse, mais je pense que la question de la valeur de SQL est beaucoup plus intéressante (tout comme d’autres, apparemment.)

J'ai beaucoup d'expérience avec SQL et je pense bien comprendre ses forces et ses faiblesses. Mon sentiment personnel est qu’il a été surexploité et abusé, mais que l’idée que nous ne devrions jamais l’utiliser est un peu ridicule. L'idée qu'il faut choisir 'SQL toujours' ou 'SQL jamais' est une fausse dichotomie.

En ce qui concerne l'injection SQL comme argument pour ne pas utiliser SQL, c'est risible. C'est un problème bien compris avec une solution assez simple. Le problème avec cet argument est que SQLi n'est pas la seule vulnérabilité existante. Si vous pensez que l'utilisation des API JSON vous sécurise, vous serez surpris.

Je pense que tous les développeurs devraient visionner cette vidéo intitulée "Vendredi 13: Attaque de JSON - Alvaro Muñoz & Oleksandr Mirosh - AppSecUSA 2017"

Si vous n'avez ni le temps ni l'envie de regarder à travers, voici l'essentiel: De nombreuses bibliothèques de désérialisation JSON comportent des vulnérabilités d'exécution de code à distance. Si vous utilisez XML, vous avez encore plus à vous inquiéter. L'interdiction de SQL à partir de votre architecture ne rendra pas votre système sécurisé.

Je veux aborder seulement une courte déclaration:

Ou veut-il simplement que les gens arrêtent d'utiliser SQL / Relational Databases en raison d'attaques SQLi?

Non, c'est une hypothèse fausse. Nous ne pouvons pas dire que nous devons cesser d'utiliser des voitures, car elles sont responsables du décès de personnes dans des accidents de voiture. De la même manière, les bases de données relationnelles / SQL (ou tout autre élément dans ce contexte, tel que le SGBDR) ne sont pas responsables des charges SQL malveillantes qu'un attaquant peut effectuer sur votre application Web. Je ne doute pas que l’auteur n’a pas voulu dire cela, car il existe une feuille de triche pour la prévention des injections SQL à cette fin.

Le problème de Martin semble être lié au fait que les programmeurs construisent du SQL dynamique directement à partir d'une entrée utilisateur, par exemple (pardonnez-moi, je suis principalement un programmeur C et C ++):

sprintf( query, "select foo from bar where %s;", user_input );

qui est absolument une recette pour les brûlures d'estomac (d'où le strip Bobby Tables ). Tout programmeur qui met un tel code dans un système de production mérite une paddlin '.

Vous pouvez atténuer (voire éliminer complètement) le problème en utilisant des instructions préparées et en nettoyant correctement vos entrées. Si vous pouvez masquer le code SQL derrière une API de telle sorte que les programmeurs ne construisent pas directement de chaînes de requête, tant mieux (ce qui fait partie de ce que préconise Martin).

Mais quant à la suppression complète de SQL, je ne pense pas que ce soit pratique ou souhaitable. Les modèles relationnels sont utiles , c'est pourquoi ils existent tout d'abord, et SQL est probablement la meilleure interface pour travailler avec des modèles relationnels.

Comme toujours, il s’agit d’utiliser le bon outil pour le poste. Si votre application de panier d'achat n'a pas besoin d'un modèle relationnel complet, n'utilisez pas de modèle relationnel (cela signifie que vous n'avez pas besoin d'utiliser SQL). Pour les moments où vous avez besoin d'un modèle relationnel, alors vous allez certainement travailler avec SQL.

Les deux sources que vous associez véhiculent des messages différents:

L'article de blog dit que la logique d'accès aux données ne devrait pas exister sous forme de texte au moment de l'exécution, sinon elle serait mélangée à une entrée utilisateur non fiable. C'est-à-dire que l'article de blog condamne l'écriture de requêtes en concaténant des chaînes.

La conférence est différente. La première différence est dans le ton: la conférence spécule et remet en question, mais ne condamne pas. Il ne dit pas que les bases de données sont diaboliques, mais nous met au défi d'imaginer la persistance sans base de données. Il fait valoir qu'au cours des 30 années écoulées depuis que les bases de données relationnelles se sont généralisées, beaucoup de choses ont changé et met en exergue deux facteurs susceptibles d'affecter notre choix de technologie de persistance:

• l’espace de stockage a été multiplié par environ 1 million - à des prix comparables! Par conséquent, il est moins nécessaire de conserver le stockage, et en particulier, il n'est plus nécessaire de supprimer. En utilisant le stockage avec ajout uniquement, le contrôle des accès simultanés peut être simplifié, car les verrous en lecture sont inutiles. Cela peut éliminer le besoin de transactions.
• les temps d'accès ont diminué, car la plupart des jeux de données sont désormais stockés dans la RAM, ce qui réduit considérablement le temps de latence des lectures.

Ces changements de circonstances changent-ils la technologie de persistance optimale? Fait intéressant, oncle Bob ne dit pas - probablement parce qu’il pense qu’aucune réponse ne serait correcte pour tous les programmes. C'est pourquoi il nous met en garde de traiter notre choix de technologie de persistance comme un détail plutôt que de l'enregistrer dans des tablettes de pierre et de le transmettre comme une sagesse reçue à nos pairs.

Existe-t-il des alternatives?

L'écriture de logique d'accès aux données sans chaînes est tout à fait possible. En Java, vous pouvez utiliser QueryDSL , dans lequel les requêtes sont décrites à l'aide d'une API fluide de type sécurisée générée à partir de votre schéma de base de données. Une telle requête pourrait ressembler à ceci:

JPAQuery<?> query = new JPAQuery<Void>(entityManager);
Customer bob = query.select(customer)
  .from(customer)
  .where(customer.firstName.eq("Bob"))
  .fetchOne();

Comme vous pouvez le constater, la logique de la requête n'est pas exprimée sous forme de chaîne, séparant clairement la structure sécurisée de la requête des paramètres non fiables (et bien entendu, QueryDSL n'inclut jamais les paramètres dans le texte de la requête, mais utilise des instructions préparées pour séparer la requête. pour ses paramètres au niveau JDBC). Pour réaliser l'injection SQL avec QueryDSL, vous devez écrire votre propre analyseur syntaxique afin d'analyser une chaîne et de la traduire en arborescence syntaxique. Même si vous procédiez ainsi, vous n'ajouteriez probablement pas de prise en charge, par exemple select ... into file. En bref, QueryDSL rend l'injection SQL impossible, améliore également la productivité du programmeur et augmente la sécurité du refactoring. Prévention du plus grand risque pour la sécurité des applications Web, qui existe depuis assez longtemps pour engendrer des gagset dynamisé la productivité des développeurs? J'ose dire que si vous écrivez toujours des requêtes sous forme de chaînes, vous le faites mal.

Pour ce qui est des alternatives aux bases de données relationnelles, il est curieux de savoir que le contrôle de la concurrence multi-version de Postgres est exactement ce genre de structure de données pour append, dont parle seulement Oncle Bob, même s'il pensait probablement davantage aux magasins d’événements , et au sourcing d’événements. motif en général, ce qui cadre aussi parfaitement avec la notion de maintien de l’état actuel dans la RAM.