Discussion :

[sam01]

Bonjour,

Squirrel nous permet de faire des select sur plusieurs type de base de données (MysqL, Postgresql, SQLserver..)

Ma question est plus sur un paramétrage de squirrel. Comment empêcher de poser des verrous sur une table lors d'une requête select.
En effet, à chaque requête de select, les utilisateur ne connaissent pas la syntaxe (ni même le concept) de verrou dans une table lors d'un select.
Par exemple, sur SQLserver, on utilise with(nolock) mais kele but est que ces paramètres soient implicite sur squirrel.

[escartefigue]

Bonjour

Si les utilisateurs ne sont pas bien formés à SQL, c'est risqué de leur mettre à disposition un outil permettant de faire des requêtes, surtout s'il s'agit de bases métier. Normalement, les utilisateurs non informaticiens ne devraient pouvoir accéder par requête qu'à des infocentres.

Sinon, le niveau d'isolation le moins restrictif est "UR" (uncommited read).
On peut donc définir ce niveau d'isolation en début de transaction ou en "current isolation" pour éviter de gêner les transactions concurrentes.
Le hic c'est qu'avec ce paramètre, non seulement les lectures ne sont pas "répétables", mais qu'aussi on peut lire des "phantom records" et des lignes non commitées et qui ne le seront peut-être jamais.

"UR" est le plus souvent utilisé quand des résultats approximatifs sont acceptables, par exemple si on veut connaître le nombre de lignes d'une table, une valeur moyenne d'une colonne, etc.

[sam01]

Bonjour.
Oui je sais qu'il faut l'option UR et je comprends ce que cela implique derrière.
Mais comme tu l'as bien compris, on a ouvert la boîte de pandor. Maintenant, il faut que l'on trouve une solution compatible avec toutes les bases de données.
La difficulté c'est que la syntaxe est différente selon les bases de données. A moins qu'il y ait unee option sur Squirrel qui permette de générer automatiquement les uncommited read quelques soit les bases de données (SQLserver, PostgreSQL, Oracle...)

[escartefigue]

La plupart des SGBD acceptent la syntaxe suivante :

set transaction isolation level READ UNCOMMITTED

[sam01]

Merci

[SQLpro]

La plupart des SGBD acceptent la syntaxe suivante :

set transaction isolation level READ UNCOMMITTED

Heu non... Enfin pas tout à fait !
Cette commande qui est conforme à la norme SQL est presque toujours supportée dans les SGBD Relationnels, mais n'a aucun effet dans la plupart !
En effet, pour les SGBDR dont le type de verrouillage est optimiste et qui n'ont pas le possibilité de faire du verrouillage pessimiste, cette commande est inopérante... C'est le cas d'Oracle ou PostGreSQL par exemple
https://blog.developpez.com/pachot/tk_isolation_levels/
Pour ces deux SGBDR le READ UNCOMMITTED est transformé en READ COMMITTED !

Enfin deux remarques :
l'usage immodéré du NOLOCK est une imbécilité car il donne des résultats faux. Lire l'article que j'ai écrit à ce sujet :
http://mssqlserver.fr/les-dangers-du-nolock/
Le fait de demander à un utilisateur d'indiquer des verrous dans une requête ne fait pas partie du SQL est est une des pires mauvais pratique !
https://www.budaconsulting.com/five-...e-query-hints/

A +

[escartefigue]

Bonjour Frédéric

l'usage immodéré du NOLOCK est une imbécilité car il donne des résultats faux. Lire l'article que j'ai écrit à ce sujet :
http://mssqlserver.fr/les-dangers-du-nolock/

Nous sommes d'accord, c'est bien pourquoi je mentionnais

Sinon, le niveau d'isolation le moins restrictif est "UR" (uncommited read).
On peut donc définir ce niveau d'isolation en début de transaction ou en "current isolation" pour éviter de gêner les transactions concurrentes.
Le hic c'est qu'avec ce paramètre, non seulement les lectures ne sont pas "répétables", mais qu'aussi on peut lire des "phantom records" et des lignes non commitées et qui ne le seront peut-être jamais.

"UR" est le plus souvent utilisé quand des résultats approximatifs sont acceptables, par exemple si on veut connaître le nombre de lignes d'une table, une valeur moyenne d'une colonne, etc.

et sur ce point :

Le fait de demander à un utilisateur d'indiquer des verrous dans une requête ne fait pas partie du SQL est est une des pires mauvais pratique !
https://www.budaconsulting.com/five-...e-query-hints/

L'erreur c'est de donner la possibilité à des utilisateurs de faire des requêtes sur le système d'information.

[sam01]

Oui effectivement, comme je l'ai dit on a ouvert la boîte de pandor en permettant cela.
Comment faîtes vous chez vous pour permettre aux utilisateurs d'interroger des tables dans interférence avec le SI ?

[escartefigue]

S'il existe un S.I. décisionnel, on vérifie si les données requises y sont, auquel cas les utilisateurs peuvent réaliser l'extraction dans le décisionnel sans perturber le S.I. métier
À défaut, s'il s'agit d'un besoin récurrent, on demande une expression de besoin, un budget et on réalise puis on met en prod un traitement réalisant l'extraction demandée

[sam01]

Merci. Je pense que tu fais allusion au Datawarehouse. Effectivement nous en avons un. Mais on ne peux pas descendre toutes les tables ded database de production dans le Datawarehouse...

[sam01]

De plus on ca ëtre confronté au dirty read à la puissance 10. Si les rables dont chargées le matin et que les utilisateurs interrogent en fin de journée.

[SQLpro]

Une solution avec SQL Server est d'utiliser un réplica AlwaysOn en lecture.

A +