Firebird Documentation Index → Firebird 1.5 Guide de démarrage → Firebird SQL |
Chaque système de gestion de base de données a ses propres particularités dans la manière d'implémenter SQL. Firebird se conforme à la norme SQL plus rigoureusement que les autres SGBD à l'exception possible de son « cousin », InterBase®. Les développeurs qui migrent depuis des produits moins conformes aux normes supposent souvent à tord que Firebird est bizarre, alors que les supposées bizarreries ne sont en fait aucunement bizarres.
Les chaînes de caractères dans Firebird sont délimitées par une paire de guillemets simples
– 'I am a string'
– (code ASCII 39,
et non pas 96). Si vous utilisiez une ancienne version de Firebird
proche d' InterBase®, vous pouvez vous souvenir que les guillemets simples et doubles
pouvaient être utilisés indifféremment pour délimiter des chaînes de caractères. Les guillemets double
ne peuvent pas être utilisés comme délimiteurs de chaîne de caractères dans des instructions SQL Firebird.
Avant la norme SQL-92, il n'était pas permis d'avoir des noms d'objets (identifiants) dans une base qui étaient un des mots clè du langage, qui étaient sensibles à la casse ou contenaient des espaces. SQL-92 a introduit une règle simple pour rendre ceci possible, à la condition que les identifiants soient definis avec une paire de guillemets doubles (ASCII 34) et qu'il soit toujours fait appel à eux en utilisant des guillemets doubles.
Le but de ce « cadeau » était de faciliter la migration de métadonnées d'un SGBD non conforme à la norme à un autre la respectant. Le désavantage de ceci, est que si vous choisissez de définir un identifiant entre guillemets doubles, la sensibilité à la casse et l'usage des guillemets doubles deviennent obligatoires.
Firebird permet un léger relâchement à cette règle selon certaines conditions très limitées. Si l'identifiant qui a été défini entre guillemets doubles :
a été écrit entièrement en majuscules,
n'est pas un mot clé, et
ne contient pas d'espaces,
... alors il peut être utilisé en SQL sans guillemet pourvu qu'il soit utilisé tout en majuscules. (Mais dès que vous mettez des guillemets doubles autour, vous devez faire attention à la casse de nouveau!)
Faites vraiment attention avec cela! Par exemple, si vous avez deux tables "TESTTABLE" et "TestTable", toutes deux définies avec des guillemets doubles, et que vous lanciez la commande:
SQL>select * from TestTable;
... vous obtiendrez les données de "TESTTABLE", pas de "TestTable"!
A moins que vous ayez une raison très convaincante pour définir des identifiants entre guillemets doubles, il est habituellement recommandé d'éviter cela. Firebird accepte volontiers un mélange d'identifiants entre guillemets ou non – il n'y a donc pas de problème à inclure un mot clé dont vous avez hérité d'une autre base de données, si vraiment vous en avez le besoin.
Certains outils d'administration de base de données appliquent systématiquement l'utilisation des guillemets doubles. Essayer de choisir un outil qui rend l'utilisation des guillemets doubles optionnelle.
Si vous devez utiliser un caractère apostrophe dans une chaîne de caractères, vous pouvez « vous en tirer » en précédant l'apostrophe avec une autre apostrophe.
Par exemple, cette chaîne de caractères renverra une erreur:
'Les jardins d'eden'
puisque lorsque l'analyseur syntaxique rencontrera l'apostrophe, il interprétera la chaîne
de caractères comme 'Les jardins d'
et ne pourra interpréter les mots suivants
qui lui seront inconnus.
pour rendre cette chaîne de caractères légale, précédez l'apostrophe avec une autre apostrophe:
'Les jardins d''eden'
Notez qu'il y a DEUX simples guillemets et non un guillemet double.
Avec SQL le symbole de concaténation est deux symboles « pipe »
(ASCII 124, une paire sans espace). Avec SQL, le symbole
« + » est l'opérateur arithmétique et causera une erreur si vous
tentez de l'utiliser pour la concaténation de chaînes de caractères. L'expression
suivante préfixe une colonne de type caractères avec les caractères
« Rapporté par:
»:
'Rapporté par: ' || LastName
Faites attention lors de concaténations. Firebird produira une erreur si votre expression tente de concaténer deux ou plusieures colonnes de type char ou varchar qui après concaténation pourraient excéder la longueur maximum permise d'un type char ou varchar (32 Kb).
Voir aussi la note ci-dessous, Expressions impliquant NULL, à propos de la concaténation
dans les expressions qui impliquent NULL
.
Firebird est conforme à la norme SQL en tronquant le résultat (quotient) d'un entier par un entier au prochain entier plus petit. Cela peut donner d'étranges résultats à moins que vous soyez conscient de cela.
Par exemple, ce calcul est correct en SQL:
1 / 3 = 0
Si vous faites la mise à jour depuis un SGBD qui résoud les divisions entier/entier en un quotient de type nombre à virgule flottante (float), vous devrez modifier les expressions concernées pour utiliser un nombre à virgule flottante ou un type numérique proportionné pour le dividende, le diviseur, ou les deux.
Par exemple, le calcul ci-dessus pourrait être modifié ainsi afin de produire un résultat différent de zéro:
1.000 / 3 = 0.333
En SQL, NULL
n'est pas une valeur. C'est une
condition, ou un état, d'un item de données, pour lequel
la valeur est inconnue. Puisque la valeur est inconnue, NULL
ne peut se comporter comme une valeur. Lorsque vous tentez d'effectuer de l'arithmétique avec
NULL
, ou l'impliquer avec des valeurs dans d'autres
expressions, le résultat de l'opération sera toujours
NULL
. Ce n'est pas un zéro ou un blanc ou une « chaîne
vide » et ne se comporte pas comme aucune de ces valeurs.
Ainsi, voici quelques exemples du type de surprises que vous obtiendrez
si vous tentez de faire des calculs ou des comparaisons avec
NULL
:
1 + 2 + 3 +
NULL
=
NULL
not (
NULL
) =
NULL
'Home ' || 'sweet ' ||
NULL
=
NULL
if (a = b) then MyVariable = 'Equal'; else MyVariable = 'Not equal';
Après l'exécution de ce code, MyVariable
retournera
'Not equal'
si a
et
b
sont NULL
. Cela provient du fait que
l'expression 'a = b'
retourne
NULL
si une au moins des composantes est
NULL
. Dans un contexte de type
« if...then
» ,
NULL
se comporte comme FALSE
.
Donc le bloc 'then
' est ignoré, et le bloc
'else
' exécuté.
if (a <> b) then MyVariable = 'Not equal'; else MyVariable = 'Equal';
Ici, MyVariable
retournera
'Equal'
si a
est
NULL
et b
ne l'est pas, ou vice
versa. L' explication est analogue à celle du premier
exemple.
FirstName || ' ' || LastName
retournera NULL
si soit
FirstName
ou LastName
sont
NULL
.
Pensez à NULL
comme étant
INCONNU
et tous ces étranges exemples soudainement
prendront sens! Si la valeur d'un Nombre
est
inconnue, le résultat de '1 + 2 + 3 + Number
' est
aussi inconnu (et donc NULL
). Si le contenu
de MyString
est inconnu, alors il en est de même pour
'MyString || YourString
' (même si
YourString
est non-NULL
).
Etc...
Firebird Documentation Index → Firebird 1.5 Guide de démarrage → Firebird SQL |