SQLite serait-il moins utile sans accepter des insertions de valeurs non numériques dans des colonnes numériques?

Dans SQLite, l'instruction suivante réussirait et la chaîne serait insérée / mise à jour dans la SALARYcolonne de type INTEGER:

update employee set salary='TOO MUCH' where emp_id=1;

Notez que zéro ne sera pas inséré / mis à jour mais la chaîne "TOO MUCH" réelle , donc il ne s'agit pas de conversion de type authomatique.

La FAQ indique:

C'est une fonctionnalité , pas un bug. SQLite utilise le typage dynamique. Il n'applique pas les contraintes de type de données. Les données de tout type peuvent (généralement) être insérées dans n'importe quelle colonne. Vous pouvez placer des chaînes de longueur arbitraire dans des colonnes entières, des nombres à virgule flottante dans des colonnes booléennes ou des dates dans des colonnes de caractères. Le type de données que vous affectez à une colonne dans la commande CREATE TABLE ne limite pas les données qui peuvent être placées dans cette colonne. Chaque colonne peut contenir une chaîne de longueur arbitraire. (Il existe une exception: les colonnes de type INTEGER PRIMARY KEY ne peuvent contenir qu'un entier signé 64 bits. Une erreur se produit si vous essayez de placer autre chose qu'un entier dans une colonne INTEGER PRIMARY KEY.)

Donc, ce comportement est clairement intentionnel, néanmoins je me demande pourquoi SQLite a ce comportement, car la plupart des autres bases de données SQL que je connais se comportent assez différemment, elles génèrent une erreur ou convertissent la chaîne 0, lorsque vous essayez d'insérer une chaîne non numérique dans une colonne numérique.

• La bibliothèque SQLite serait-elle moins utile sans ce comportement?

• Est-ce fait de par la conception pour garder la bibliothèque petite et rapide?

• La bibliothèque SQLite serait-elle considérablement plus lente ou plus grande afin d'augmenter les erreurs lors de la tentative d'insertion d'une chaîne dans une colonne numérique?

Non, la frappe dynamique nécessite à la fois plus d'espace de stockage et plus de temps de traitement, d'autant plus qu'ils ajoutent également une affinité de type, ce qui signifie qu'il a un type préféré que le programmeur est libre d'ignorer. C'est vraiment une caractéristique intentionnelle avec des coûts de compromis réels. Ces coûts sont effectivement négligeables pour les cas d'utilisation des cibles SQLite, mais ils sont toujours là.

L'utilité de telles fonctionnalités est difficile à voir car vous n'êtes pas habitué à les avoir à votre disposition. La solution pour son manque vous semble plus naturelle maintenant. En raison de votre expérience antérieure, vous le considérez comme un champ INTEGER qui ne sera jamais rien d'autre, mais SQLite le voit plus comme un champ de tout type, mais contiendra probablement principalement des entiers. Il s'agit peut-être d'un code postal pour une entreprise qui fait principalement des affaires aux États-Unis, mais qui compte une poignée de clients canadiens. Permettre à l'utilisateur de spécifier une affinité entière économisera beaucoup d'espace en en faisant une chaîne dans chaque ligne, mais vous donne toujours cette option.