Veillez à ce que les requêtes soient uniquement "raisonnables".

Question

Dans notre organisation, nous avons besoin de laisser les employés filtrer les données dans notre application web en fournissant des clauses WHERE. Ce système fonctionne parfaitement depuis longtemps, mais il arrive que des utilisateurs fournissent des requêtes qui nécessitent des analyses complètes de grandes tables ou des jointures inefficaces, etc.

Un clown pourrait écrire quelque chose comme :

select * from big_table where
Name in (select name from some_table where name like '%search everything%')
or name in ('a', 'b', 'c')
or price < 20
or price > 40
or exists (select 1 from some_other_table where col1 + col2 + col3 = 4)
or exists (select 1 from table_a, table+b)

Évidemment, ce n'est pas une bonne façon d'interroger ces tables avec des valeurs calculées, des colonnes non indexées, beaucoup de OU et une jointure sans restriction sur table_a et table_b.

Mais pour un utilisateur, cela peut être tout à fait logique.

Quel est donc le meilleur moyen, le cas échéant, de permettre aux utilisateurs internes de fournir une requête à la base de données tout en garantissant qu'elle ne verrouillera pas une douzaine de tables et ne bloquera pas le serveur web pendant 5 minutes ?

Je suppose qu'il s'agit d'un moyen programmatique en c#/sql-server pour obtenir le plan d'exécution d'une requête avant son exécution. Et si c'est le cas, quels facteurs contribuent au coût ? Coût estimé des E/S ? Coût estimé du CPU ? Quelles seraient les limites raisonnables pour dire à l'utilisateur que sa requête n'est pas bonne ?

EDIT : Nous sommes une société d'études de marché. Nous avons des milliers d'enquêtes, chacune avec ses propres données. Nous avons des dizaines de chercheurs qui veulent découper ces données de manière arbitraire. Nous disposons d'outils qui leur permettent de construire des filtres "valides" à l'aide d'une interface graphique, mais certains "utilisateurs expérimentés" veulent fournir leurs propres requêtes. Je me rends compte que ce n'est pas la norme ou la meilleure pratique, mais comment faire autrement pour permettre à des dizaines d'utilisateurs d'interroger des tables pour obtenir les lignes qu'ils veulent en utilisant des conditions arbitrairement complexes et des conditions qui changent constamment ?

Answer 1

Vous pouvez créer un modèle de données pour votre base de données et permettre aux utilisateurs d'utiliser le Report Builder de SQL Reporting Services. Il s'agit d'une interface graphique qui ne nécessite pas l'écriture de clauses WHERE, ce qui devrait limiter les dégâts qu'ils peuvent causer.

Ou vous pouvez stocker une copie de la base de données pour les requêtes des utilisateurs, mettre à jour la base de données toutes les heures environ, et les laisser faire... :)

Answer 2

J'ai travaillé dans quelques endroits où cela se produisait également. Ce que nous avons fini par faire, c'est de NE PAS autoriser les utilisateurs à accéder librement aux données, et de promettre que le service informatique ferait de son mieux pour fournir des requêtes si nécessaire. Le problème était que la base de données est assez complexe et que même si les utilisateurs pouvaient écrire un SQL grammaticalement et syntaxiquement correct, ils ne comprenaient pas nécessairement les relations entre les tables. En d'autres termes, même s'ils pouvaient écrire leur propre SQL, ils obtiendraient de mauvaises réponses. Nous avons convaincu les utilisateurs que le risque de prendre une mauvaise décision sur la base d'une compréhension imparfaite ou incomplète des 200 tables de la base de données était trop élevé. Mieux valait obtenir la bonne réponse au bout d'une journée que la mauvaise immédiatement.

L'autre partie de la question est de savoir ce que fait l'informatique lorsqu'un utilisateur A écrit une requête et obtient une réponse, puis qu'un utilisateur B écrit ce qu'il pense être la même requête et obtient une réponse différente. Est-ce le rôle de l'informatique de trouver les différences ? De corriger les deux morceaux de SQL ? etc. En résumé, je ne leur accorderais pas l'accès. Je chargerais le système avec des requêtes prédéfinies, comme d'autres l'ont mentionné, et j'essaierais de former la direction pour qu'elle comprenne que c'est la seule façon de fonctionner à long terme.

Answer 3

Si vous disposez d'un grand nombre de données et que vous souhaitez offrir à vos clients la possibilité d'analyser et de consulter ces informations comme ils le souhaitent, je vous recommande vivement de vous pencher sur les points suivants OLAP technologies.

Answer 4

Je suppose que vous n'avez jamais entendu parler des attaques par injection SQL ? Que se passe-t-il si l'utilisateur entre une commande DROP DATABASE après la clause WHERE ?

Answer 5

C'est la raison pour laquelle l'autorisation SELECT directe n'est presque jamais donnée aux utilisateurs dans la grande majorité des applications.

Une bien meilleure approche consisterait à concevoir votre application en fonction des cas d'utilisation, de manière à pouvoir couvrir un pourcentage raisonnable des besoins grâce à des options de filtrage, d'agrégation et de présentation spécialement conçues.

Il existe une myriade de moyens d'y parvenir. Une analyse de votre problème spécifique sera donc nécessaire, ainsi que la recherche de méthodes viables.

Si l'accès direct à SQL est le plus souple pour vos utilisateurs, l'exécution de longues requêtes ne sera probablement que le début de vos maux de tête. L'injection SQL est une préoccupation majeure dans ce domaine, que sa source soit malveillante ou simplement malavisée.