SQLite 3.37 est disponible, le moteur de base de données léger apporte le mode STRICT tant attendu,

Une amélioration de l'interface CLI et plus

Le 29 novembre 2021 à 16:59, par Bruno

63PARTAGES

L'équipe de développement de SQLite a annoncé le 27 novembre la sortie de la version 3.37 de SQLite. Cette version apporte le mode STRICT qui est activé séparément pour chaque table d’une base de données. « Certains développeurs apprécient la liberté qu'offrent les règles de typage flexibles de SQLite et utilisent cette liberté à leur avantage. Mais d'autres développeurs sont choqués par le non-respect flagrant des règles par SQLite et préfèrent le système de typage rigide traditionnel que l'on trouve dans tous les autres moteurs de base de données SQL et dans le standard SQL. Pour ce dernier groupe, la version 3.37 de SQLite supporte un mode de typage STRICT qui est activé séparément pour chaque table », a déclaré l'équipe de développement de SQLite.

Rappelons que SQLite est un moteur de base de données relationnelle léger accessible par le langage SQL. Contrairement aux serveurs de bases de données traditionnels, comme MySQL ou PostgreSQL, sa particularité est de ne pas reproduire le schéma habituel client-serveur, mais d'être directement intégrée aux programmes. L'intégralité de la base de données (déclarations, tables, index et données) est en effet stockée dans un fichier indépendant de la plateforme. Grâce à son extrême légèreté, SQLite est l’un des moteurs de base de données les plus utilisés au monde. Il est utilisé dans de nombreux logiciels grand public, et est également très populaire sur les systèmes embarqués, notamment sur la plupart des smartphones modernes.

Table STRICT

SQLite s'efforce d'être flexible en ce qui concerne les types de données du contenu qu'il stocke. Par exemple, si une colonne de la table a pour type "INTEGER", SQLite essaie de convertir tout ce qui est inséré dans cette colonne en un nombre entier. Ainsi, une tentative d'insertion de la chaîne '123' se traduit par l'insertion d'un nombre entier 123. Mais si le contenu ne peut pas être converti sans perte en un nombre entier, par exemple si l'entrée est 'xyz', alors la chaîne originale est insérée à la place.

Certains développeurs apprécient la liberté qu'offrent les règles de typage flexibles de SQLite et utilisent cette liberté à leur avantage. Mais d'autres développeurs sont choqués par le non-respect flagrant des règles par SQLite et préfèrent le système de type rigide traditionnel que l'on trouve dans tous les autres moteurs de base de données SQL et dans le standard SQL. Pour ce dernier groupe, SQLite supporte un mode de typage strict, à partir de la version 3.37.0, mode qui est activé séparément pour chaque table.

Dans une instruction CREATE TABLE, si le mot-clef "STRICT" est ajouté à la fin, après le "

" de fermeture, les règles de saisie stricte s'appliquent à cette table. Le mot-clef STRICT entraîne les différences suivantes :

chaque définition de colonne doit spécifier un type de données pour cette colonne, la liberté de spécifier une colonne sans type de données est supprimée ;
le type de données doit être l'un des types suivants.

INT
INTEGER
REAL
TEXT
BLOB
ANY

Le contenu inséré dans la colonne avec un type de données autre que ANY doit être soit un NULL (en supposant qu'il n'y a pas de contrainte NOT NULL sur la colonne) ou le type spécifié. SQLite tente de contraindre les données dans le type approprié en utilisant les règles d'affinité habituelles, comme le font PostgreSQL, MySQL, SQL Server et Oracle. Si la valeur ne peut pas être convertie sans perte dans le type de données spécifié, alors une erreur SQLITE_CONSTRAINT_DATATYPE est levée.

Les colonnes avec le type de données ANY peuvent accepter n'importe quel type de données (sauf qu'elles rejetteront les valeurs NULL si elles ont une contrainte NOT NULL, bien sûr). Aucune coercition de type ne se produit pour une colonne de type ANY dans une table STRICT. Les colonnes qui font partie de la CLEF PRIMAIRE sont implicitement NOT NULL. Cependant, même si la PRIMARY KEY a une contrainte NOT NULL implicite, lorsqu'une valeur NULL est insérée dans une colonne INTEGER PRIMARY KEY, la valeur NULL est automatiquement convertie en un entier unique, en utilisant les mêmes règles que pour INTEGER PRIMARY KEY sur les tables ordinaires, non strictes. Les commandes PRAGMA integrity_check et PRAGMA quick_check vérifient le type du contenu de toutes les colonnes des tables STRICT et affichent des erreurs si quelque chose ne va pas. Toutes les autres fonctions d'une table STRICT sont identiques à celles d'une table ordinaire non stricte.

Le type de données ANY

La possibilité d'héberger tout type de données dans une seule colonne s'est avérée remarquablement utile au fil des ans. Afin de continuer à soutenir cette capacité, même dans les tables STRICT, le nouveau nom de type de données ANY est introduit. Lorsque le type de données d'une colonne est "ANY", cela signifie que n'importe quel type de données - entiers, valeurs à virgule flottante, chaînes de caractères ou blobs binaires - peut être inséré dans cette table et sa valeur et son type de données seront préservés exactement comme il a été inséré. Pour autant que nous le sachions, SQLite est le seul moteur de base de données SQL qui supporte cette capacité avancée.

Le comportement de ANY est légèrement différent dans une table STRICT par rapport à une table ordinaire non stricte. Dans une table STRICT, une colonne de type ANY préserve toujours les données exactement comme elles sont reçues. Dans une table ordinaire non stricte, une colonne de type ANY tentera de convertir les chaînes qui ressemblent à des nombres en une valeur numérique et, si elle y parvient, stockera la valeur numérique plutôt que la chaîne d'origine.

Pour certains analystes, le prochain projet de l'équipe de développement de SQLite devrait être l’ajout de l’instruction CREATE DOMAIN qui permet de définir un alias de type personnalisé. Notons qu’un domaine SQL est un ensemble nommé de valeurs valides défini par l'utilisateur. Les domaines dépendent d'un certain schéma. Le domaine doit être unique au sein du schéma auquel il appartient (il ne peut pas non plus être identique à tout dans son schéma). Les domaines sont créés, modifiés et supprimés à l'aide d'instructions SQL standard. Les objets qui peuvent appartenir à un domaine sont connus sous le nom de contraintes de domaine et ils dépendent d'un certain domaine.

Pour créer un domaine, l’instruction CREATE DOMAIN est utilisée. Cette instruction crée un nouveau domaine. Un domaine est essentiellement un type de données avec des contraintes optionnelles (restrictions sur l'ensemble de valeurs autorisées). L'utilisateur qui définit un domaine devient son propriétaire. Si un nom de schéma est donné (par exemple, CREATE DOMAIN monschema.mondomaine ...), alors le domaine est créé dans le schéma spécifié. Sinon, il est créé dans le schéma courant. Le nom du domaine doit être unique parmi les types et domaines existant dans son schéma.

Les domaines permettent d'extraire des contraintes communes à plusieurs tables et de les regrouper en un seul emplacement, ce qui en facilite la maintenance. Par exemple, plusieurs tables pourraient contenir des colonnes d'adresses email, toutes nécessitant la même contrainte de vérification (CHECK) permettant de vérifier que le contenu de la colonne est bien une adresse email. Définissez un domaine plutôt que de configurer la contrainte individuellement sur chaque table.

CREATE DOMAIN spécifie le schéma englobant, nomme le domaine et identifie l'ensemble des valeurs valides du domaine. Pour modifier un domaine existant, l'instruction ALTER DOMAIN est utilisée et DROP DOMAIN est utilisée pour détruire un domaine. Sans CREATE DOMAIN, les tables STRICT ne savent pas quel type de base utiliser pour un nom de type inconnu. Ils pourraient utiliser quelque chose comme « les types inconnus sont équivalents à ANY » mais cela signifierait qu'ils ne pourraient pas implémenter CREATE DOMAIN à l'avenir sans rompre la compatibilité ascendante.

PostgreSQL serait le seul moteur de base de données relationnelle majeure à implémenter CREATE DOMAIN, bien qu'il y ait quelques SGBDR plus qui le supportent aussi (comme Firebird, Interbase, Sybase/SAP SQL). L'équipe de développement de SQLite n'a pas indiqué qu'elle prévoyait de travailler sur CREATE DOMAIN. Cependant, même si certains développeurs apprécient la liberté qu'offrent les règles de typage flexibles de SQLite et utilisent cette liberté à leur avantage, d'autres par contre sont choqués par le non-respect flagrant des règles par SQLite et préfèrent le système de type rigide traditionnel que l'on trouve dans tous les autres moteurs de base de données SQL.

« Je pense que c'est le genre de fonctionnalité susceptible de les séduire, elle devrait être relativement simple à mettre en œuvre (surtout s'ils ne mettent pas en œuvre ALTER DOMAIN, seulement CREATE et DROP), mais fournir beaucoup de puissance en échange. », déclare un développeur.

Améliorations de l'interface CLI

Le projet SQLite fournit un programme de ligne de commande simple nommé sqlite3 (ou sqlite3.exe sous Windows) qui permet à l'utilisateur de saisir et d'exécuter manuellement des instructions SQL contre une base de données SQLite ou contre une archive ZIP. Ce document fournit une brève introduction sur la façon d'utiliser le programme sqlite3. Par exemple, pour créer une nouvelle base de données SQLite nommée ex1 avec une seule table nommée tbl1, vous pouvez procéder comme suit :

Code :

Sélectionner tout

1
2
3
4
5
6
7
8
9
10
$ sqlite3 ex1
SQLite version 3.36.0 2021-06-18 18:36:39
Enter ".help" for usage hints.
sqlite> create table tbl1(one varchar(10), two smallint);
sqlite> insert into tbl1 values('hello!',10);
sqlite> insert into tbl1 values('goodbye', 20);
sqlite> select * from tbl1;
hello!|10
goodbye|20
sqlite>

Voici, ci-dessous, quelques améliorations et ajouts qu’apporte la version 3.37 de SQLite à l'interface CLI :

amélioration des performances lors de la lecture des instructions SQL qui s'étendent sur plusieurs lignes ;
ajout de la commande .connection, qui permet à l'interface CLI de maintenir plusieurs connexions de base de données ouvertes en même temps ;
ajout de l'option de ligne de commande --safe qui désactive les commandes point et les instructions SQL susceptibles de provoquer des effets secondaires allant au-delà du fichier de base de données unique nommé sur la ligne de commande.

Source : SQLite

Et vous ?