[Commentaires] Qu'est-ce qu'il manque selon vous à SQL-Server ? [Résolu]

[fsmrel]

*** Ce sujet permet de commenter les choses qui manquent selon vous à SQL-Server, issues de ce sujet :
http://www.developpez.net/forums/d10...lon-sql-server

Envoyé par zoltix

Dans l’algèbre SQL la différence.

L'opération de différence existe. Simplement au lieu d'être appelée DIFFERENCE ou, comme dans l'algèbre relationnelle, MINUS, conformément à la norme SQL elle est appellée EXCEPT.

[fsmrel]

Envoyé par aieeeuuuuu

Pour ma part, je commencerai par la déférabilité des contraintes !

Par rapport à la norme SQL, vous avez bien raison. Mais l’application différée des contraintes prônée par la norme n’est une bonne chose. Au nom de la garantie de l’intégrité des données, il est de loin préférable que tout se passe au sein d’un bloc d’instructions (multiple assignment), comme dans l’exemple ici.

Pour les motifs profonds de la disqualification des contrôles différés, reportez-vous par exemple à l’ouvrage SQL and Relational Theory, pages 171 et suivantes.

[Oishiiii]

Envoyé par elsuket

Le type bit répond à cela, et il est normal qu'il puisse être à NULL.

Non. L'implémentation d'un type Booléen implique des conséquences plus profondes et très utiles comme l'explique Chris Date.

La requête suivante retourne une valeur de type entier :

Code :

SELECT 1+1;

De la même manière il devrait être possible de retourner directement dans la clause SELECT une valeur booléenne, qui serait le résultat d'une expression.. booléenne donc.
Il devrait être possible d'écrire les requêtes suivantes :

Code :

1
2
3
SELECT EXISTS (
  SELECT * FROM msdb.sys.DATABASES WHERE name='nomBdd'
)

Code :

SELECT ISNUMERIC(5);

ou encore

Code :

1
2
3
SELECT *
FROM maTable
WHERE maFonction(uneColonne);

On pourrait imaginer que cette valeur booléenne soit directement utilisée dans nos langages de programmation (qui supportent un vrai type booléen) :

Code :

1
2
3
4
5
IF(maRequêteSQL) {
-- traitement si TRUE
} ELSE {
-- traitement si FALSE
}

[elsuket]

OK, j'y vois un peu plus clair dans votre expression.

Je suis d'accord sur l'addition, qui devrait provoquer une erreur.

En revanche sur l'EXISTS d'une requête, je pense (à tort peut-être !) que c'est un prédicat, donc je trouve normal que votre exemple ne fonctionne pas.

L'exemple d'utilisation de ISNUMERIC() que vous donnez fonctionne et retourne bien 1.

Idem pour la clause WHERE avec une fonction, définie par l'utilisateur ou native.
En revanche c'est assez contre-performant.

Merci pour la référence au livre de Chris Date, je vais m'empresser de me le procurer.

@++

[fsmrel]

Bonsoir,

Envoyé par elsuket

Le type bit répond à cela

Hum...

Je cite la référence SQL Server à propos du type BIT :

« An integer data type that can take a value of 1, 0, or NULL. »

Pour sa part, Oishiiii a fait mention d’un vrai type booléen (BOOLEAN). Que je sache, d’après la citation ci-dessus, le type BIT n’est jamais qu’une spécialisation du type INT, avec lequel on passe de la logique des prédicats à un simulacre, à un ersatz, à de l’épicerie.

NULL (que par ailleurs l’auteur de la référence considère comme une valeur, alors que ça n’est qu’une marque !) ne fait pas partie des valeurs possibles pour le type booléen, qui sont limitées à TRUE, FALSE, point barre. La norme autorise pour sa part TRUE, FALSE, UNKNOWN, mais je n’entrerai pas dans la polémique, je l’ai fait assez souvent chez DVP.

Par ailleurs, il y a du mou dans la corde à nœuds avec ce type BIT, car si je code :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
 
CREATE TABLE A
(
      COLA    BIT
   ,  COLB    CHAR(1)
) ;
 
INSERT INTO A VALUES (0, 'A') ;
INSERT INTO A VALUES (3.14, 'B') ;
 
SELECT * FROM A
WHERE COLA = 'TRUE' ;

Le résultat fourni est le suivant :

Code :

1
2
3
4
 
COLA    COLB
----    ----
   1    B

Or je ne sache pas que 3.14 = 1.

Quand l’auteur de la référence écrit :

« The string values TRUE and FALSE can be converted to bit values: TRUE is converted to 1 and FALSE is converted to 0. »

Il a tout faux, car il y a conversion non pas de TRUE et FALSE mais de 'TRUE' et 'FALSE', qui ne sont pas des valeurs de type booléen, mais de type chaîne de caractères. On nage dans l’approximation (l'arnaque ?) la plus totale.

Encore un mot à propos de la norme SQL :

« The data type boolean comprises the distinct truth values True and False. Unless prohibited by a NOT NULL constraint, the boolean data type also supports the truth value Unknown as the null value. This specification does not make a distinction between the null value of the boolean data type and the truth value Unknown that is the result of an SQL <predicate>, <search condition>, or <boolean value expression>; they may be used interchangeably to mean exactly the same thing. »

Vous avez bien lu ? Selon la norme, il revient au même de dire : « Je ne sais pas » et « Je sais que l’information est absente » ! Etc.

[fsmrel]

Envoyé par zinzineti

S'il y a une suggestion à faire à MS à propos de SQL SERVER c'est d'abord et avant tout de commencer par corriger les anomalies remontées par les utilisateurs.

Très bon préambule

[elsuket]

Merci fmsrel.
En fait je ne me suis jamais rendu compte de ces anomalies parce que je maintiens mes bases de données de façon très stricte.

Même si ce genre d'anomalies devrait plutôt générer une erreur que "passer", je pense qu'elles relèvent plus d'une mauvaise utilisation de SQL Server donc bien des éditeurs profitent ou ont demandé à profiter ...

Pourquoi cette course aux versions ? Parce que pour vendre des lames de rasoir comme des logiciels, il faut y ajouter (ou faire croire qu'on y a ajouté, ce qui est plus vrai dans le cas des lames de rasoir ) de nouvelles fonctionnalités

@++

[fsmrel]

De rien Nicolas,

Envoyé par elsuket

je ne me suis jamais rendu compte de ces anomalies parce que je maintiens mes bases de données de façon très stricte.

Ce dont on ne peut que vous féliciter. Confidence pour confidence, je n’avais jamais utilisé le type BIT et du coup je l’ai testé en tapant n’importe quoi, histoire de voir le genre de message d’erreur produit... Quelle ne fut pas ma surprise !

[elsuket]

Je n'en doute pas

Pour en revenir à un exemple donné par Oishiiii, SELECT 1+1 retourne 2, puisque ces deux entiers sont considérés en tant que tel (=> int)

En revanche, si l'on exécute :

Code :

SELECT CAST(1 AS bit) + CAST(1 AS bit)

Nous obtenons :

Msg 8117, Level 16, State 1, Line 1
Operand data type bit is invalid for add operator.

Enfin, pour reprendre l'exemple de fmsrel, et là est un gros problème :

Code :

SELECT CAST(3.14 AS bit)

retourne 1, et ça, c'est très moche

@++

[elsuket]

Est ce qu'on va attendre encore 10 ans pour mettre des TRY ...CATCH dans les UDFs (CREATE FUNCTION ....) ?

Je ne suis pas d'accord là-dessus.
Une fonction retourne une valeur, et par là même est susceptible d'être appelée dans une requête.
C'est donc pour cela qu'il n'y a pas de gestion d'erreur faisable dans les fonctions.

@++

[Waldar]

Envoyé par fsmrel

Par rapport à la norme SQL, vous avez bien raison. Mais l’application différée des contraintes prônée par la norme n’est une bonne chose. Au nom de la garantie de l’intégrité des données, il est de loin préférable que tout se passe au sein d’un bloc d’instructions [...]

Est-ce que les contraintes déférées posent un vrai problème, puisqu'elles sont fort heureusement toujours contrôlées lors de la fin de la transaction ?

Vérifions avec Oracle :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
CREATE TABLE t1_master
(
    c1   int,
    constraint pk_t1_master
      PRIMARY KEY (c1)
      deferrable
);
-- Table created.
 
CREATE TABLE t2_slave
(
    c1   int,
    constraint pk_t2_slave
      PRIMARY KEY (c1),
    constraint fk_t2_slave_t1_master
      FOREIGN KEY (c1)
      REFERENCES t1_master (c1)
      initially deferred
);
-- Table created.
 
INSERT INTO t1_master (c1) VALUES (1);
-- 1 row created.
INSERT INTO t1_master (c1) VALUES (2);
-- 1 row created.
INSERT INTO t2_slave (c1) VALUES (1);
-- 1 row created.
INSERT INTO t2_slave (c1) VALUES (2);
-- 1 row created.
commit;
-- Commit complete.

Supprimons un maître, et rendons à un esclave sa liberté :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
DELETE FROM t1_master WHERE c1 = 2;
-- 1 row deleted.
 
SELECT * FROM t1_master;
        C1
----------
         1
 
SELECT * FROM t2_slave;
        C1
----------
         1
         2

Diantre ! Les données sont-elles corrompues ?

Code :

1
2
3
4
commit;
 
ORA-02091: transaction annulée
ORA-02292: violation de contrainte (FK_T2_SLAVE_T1_MASTER) d intégrité - enregistrement fils existant

Ouf, la transaction a été annulée. Les contraintes déférées ne présentent donc pas de risque au niveau de l'intégrité des données !

[zinzineti]

Envoyé par elsuket

Je ne suis pas d'accord là-dessus.
Une fonction retourne une valeur, et par là même est susceptible d'être appelée dans une requête.
C'est donc pour cela qu'il n'y a pas de gestion d'erreur faisable dans les fonctions.

@++

Prenons un cas concret

Problème : essayons d'écrire la fonction ISDATE2 qui retourne 1 si l'expression entrée est une valeur DATETIME2 valide sinon retourne 0

Constat
Impossible d'écrire cette fonction ISDATE2 avec des TRY et CATCH à l'intérieur

Solution de contournement

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
CREATE PROCEDURE P_IsDate2(@dateStr NVARCHAR(20), @retour INT OUTPUT)
AS
BEGIN
DECLARE @datetime2 datetime2
 
BEGIN TRY
    SELECT  @datetime2 = CONVERT(DATETIME2, @dateStr)
    SELECT @retour = 1     
END TRY
BEGIN CATCH
    SELECT @retour = 0
END CATCH
END
 
--Utilisation de la procédure P_IsDate
DECLARE @re INT 
EXEC P_IsDate2 N'0001-01-01',@re OUTPUT
IF (SELECT @re) = 1
PRINT 'VALID'
ELSE
PRINT 'INVALID'
 
--Résultat : VALID
 
DECLARE @re INT 
EXEC P_IsDate2 N'23:59:59.9999999',@re OUTPUT
IF (SELECT @re) = 1
PRINT 'VALID'
ELSE
PRINT 'INVALID'
 
--Résultat : VALID

[fsmrel]

Envoyé par Waldar

Ouf, la transaction a été annulée. Les contraintes déférées ne présentent donc pas de risque au niveau de l'intégrité des données !

Hum... Une fois que vous avez supprimé le maître 1 et que la requête « select * from t2_slave ; » affirme qu’il est toujours bien présent du fait de l’état deferred, de facto la base de données est dans un état instable (pour la seule transaction, puisqu’en cas de mise à jour le système de verrouillage interdit aux autres utilisateurs d’accéder aux tables impliquées), et l’on court tous les dangers tant que l’on n’a pas atteint un point de commit car, entre temps, il peut y avoir un sacré paquet d’instructions exécutées en toute bonne foi (on peut faire confiance en cela aux développeurs, lesquels ont parfois une imagination débordante, mais ne sont pas censés savoir que sous le capot, au niveau du DDL on a codé « initially deferred »).

La vraie solution qui garantit la stabilité est bien celle qui est préconisée par Chris Date qui disqualifie tout contrôle différé, alors que du temps de sa folle jeunesse il était pour (cf. "Immediate vs. Deferred Rules" in Relational Database, Writings 1991-1994, pages 93-94).

Comme je l’ai déjà précisé, tout contrôle peur être rendu immédiat grâce à la technique de l’affectation multiple (Multiple Assignment). A ce sujet, je vous renvoie une fois de plus à l’ouvrage SQL and Relational Theory, pages 171 et suivantes.

[elsuket]

Zinzinetti,

Je me suis mal exprimé, et pour moi ce que tu montres là est une vérification à effectuer côté applicatif (depuis quand une chaîne est une date ?)

Notes que tu peux faire cela avec une fonction d'assembly ...

@++

[zinzineti]

Envoyé par elsuket

Zinzinetti,

Je me suis mal exprimé, et pour moi ce que tu montres là est une vérification à effectuer côté applicatif (depuis quand une chaîne est une date ?)

@++

L'idée c'est d'écrire une fonction ISDATE2 pour valider des données de type DATETIME2.

La fonction native ISDATE prend bien en entrée une chaîne de caractères ou expression qui peut être convertie en une chaîne de caractères

Envoyé par elsuket

Notes que tu peux faire cela avec une fonction d'assembly ...

Eh oui ...là il faut que je sorte de SSMS pour lancer Visual Studio et commencer par coder du C# ou autre ...
Tu vois la problématique ?

Qu'est ce qui empêche/bloque MS de mettre à disposition la fonction ISDATE2 valable pour les types DATETIME2 ?

On revient à la question initiale !

A+

[elsuket]

Envoyé par Kloun

Un truc qui va faire hurler les puristes : pouvoir faire des Insert/Update/Delete sans logger.

C'est totalement inutile, et si c'est enregistré dans le fichier du journal, c'est pour garantir l'intégrité de la base de données en cas de crash par exemple ...

@++

[mikedavem]

Bonjour tout le monde,

Juste quelques remarques sur certains choses qui ont été dite. La discussion est très intéressante :-)

>> Zinzineti

S'il y a une suggestion à faire à MS à propos de SQL SERVER c'est d'abord et avant tout de commencer par corriger les anomalies remontées par les utilisateurs. Et la liste des anomalies est longue. Vous pouvez faire votre propre opinion en allant jeter un coup d'oeil sur Connect.
Personnellement je suis abasourdi de constater qu'il y a des anomalies remontées depuis SQL Server 2005 et qui ne sont toujours pas traitées jusqu'à ce jour !

Je pense qu'il ne faut pas faire l'amalgame entre corrections de bug et nouvelles fonctionnalités. Une application qui n'innove pas est une application qui est vouée à mourir (je me souviens bien de mes cours de génie logiciel ).

>> Waldar

Les constructeurs de lignes valuées qui permettent d'écrire :

Depuis 2008 il existe un tel constructeur


>> Kloun

Un truc qui va faire hurler les puristes : pouvoir faire des Insert/Update/Delete sans logger.

Vous allez à l'encontre des principes mêmes des propriétés ACID des transactions

[SQLpro]

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

Je te rejoins.
Sans parler de la notion de package, inexistante sous SQL Server qui permettrait de mettre un peu d'ordre quand il y a beaucoup de code.

Il suffit d'utiliser ce que la norme SQL à prévu, à savoir les schémas SQL trop souvent ignoré des développeurs !

A +

[SQLpro]

Envoyé par Oishiiii

Je commencerais par l'ajout:

• de l'opérateur de jointure naturelle (NATURAL JOIN)
• d'un vrai type Booléen
• des Assertions

1) NATURAL JOIN n'est pas une obligation de la norme et se trouve être plus pervers qu'autre chose vue les pratiques des développeurs de nommer les colonnes toujours de la même manière. Exemple colonne Nom dans personne etr colonne Nom dans Produit !
2) le type boolean est considéré comme deprecated dans les dernières version de la norme SQL
3) personne sauf Ocelot n'a implémenté les Assertions du fait de problèmes de performances qui peuvent s'avérer dramatiques.

A +

[SQLpro]

Envoyé par elsuket

Bonjour,


Le type bit répond à cela, et il est normal qu'il puisse être à NULL.

Pour ma part, je dirai, sous SSMS :

- possibilité de filtrer sur le nom des bases de données
- possibilité de formater le code
- possibilité d'écrire des modèles de requêtes INSERT, UPDATE, DELETE
- intégration du Profiler
- débogage des requêtes et procédures stockées simplifié
- onglets pas serveur

Certaines de ces fonctionnalités sont déjà présentes dans 2005/2008 et pour le formatage il y a des outils externes plugable dans SSMS.

Et pour le moteur de bases de données :

- possibilité de spécifier le re-calcul des statistiques de colonnes par table
- rendre impossible la compilation de code sur des objets non qualifiés (=> erreur de syntaxe)
- remplacement des instructions DBCC par des DMVs (comme DBCC SHOW_STATISTICS, ...)

Quand à rendre impossible l compilation de code sur des objets non qualifiés c'est idiot car certaines applications fonctionne sous le principe de la nom qualification par le schéma. Notamment de nombreux ERP qui crééent de nombreux schémas SQL et autant d'utilisateurs associés par défaut.
Enfin pour DBCC c'est en voie de remplacement.

A +