Lors de mes lectures et participations au forum SQL Server de ce site, je vois souvent des participants remplacer le terme ligne par enregistrement ou record, mais aussi le terme colone par le terme champ ou encore field, et enfin le pire : table par tableau, probablement par analogie de la représentation des résultats de requête avec un fichier Excel.

Si certains diront que c’est approximativement la même chose, et que s’attacher a ce type de détails revient à chercher des poils sur les Å“ufs, je vais démontrer que faire cet abus de langage montre qu’on est assez imprécis …

=> Une colonne d’une table de base de données n’est pas un champ

La différence la plus directe entre une colonne et un champ est qu’un champ est défini dans un enregistrement à destination d’une application particulière, alors qu’une colonne d’une ligne dans une table est définie en totale indépendance des applications qui liront ou modifieront ceux-ci.

Une autre discordance tout aussi importante est que toute colonne d’une table de base de données stocke des valeurs scalaires et peut surtout être NULLable, notion rarement implémentée dans tout autre langage que SQL.
Et je suis sûr que nombre d’entre nous ont déjà eu des problèmes d’intégration de données à partir de fichiers plats dans une base de données, où il faut modifier le comportement par défaut de l’outil d’intégration pour lui faire remplacer un saut de champ ou une chaîne vide du fichier pour voir son intégration dans la table cible remplacée par NULL.

Un nouvel éloignement peut être simplement mis en évidence si nous modifions l’ordre des champs que nous avons établi pour une application et que nous tentons de le faire lire à une autre application : l’ordre n’a aucune influence sur les tuples de valeurs stockées par les colonnes d’une table, car celles-ci sont directement étiquetées par leur nom, et non pas désignées par leur ordre d’apparition dans le fichier ou le flux.

Un écart plus spécifique est celui de l’impossibilité pour un champ d’être soumis à des contraintes de domaine (CHECK constraints) ou de valeur par défaut (DEFAULT constraints).

Pour en revenir aux problèmes que l’on peut rencontrer lors des intégrations de données contenues dans des fichiers plats à destinations de tables de base de données, il arrive parfois qu’il y ait discordance lors du transtypage d’un champ vers une colonne : cela est tout simplement du au typage fort des colonnes, alors que les champs ne sont pas typés.
Il s’agit alors pour le moteur d »intégration de transtyper automatiquement, par exemple, d’une chaîne de caractère vers un entier …

=> Une ligne d’une table de base de données n’est pas un enregistrement

De la même façon que pour les champs, la structure des enregistrements est déterminée pour l’usage d’une application.
Encore une fois, l’ordre physique des champs de l’enregistrement prime, alors que l’ordre des colonnes d’une ligne n’altère pas la signification du tuple représenté par une ligne de base de données : {A,B,C} en base de données signifie la même chose que {C,A,B}, ce qui n’est pas le cas dans un fichier ou un flux.

Toujours de la même manière que pour les colonnes, une ligne est définie dans un schéma de base de données, et non pas par l’application qui en est la destination.
L’illustration en est la notion d’ensemble vide : alors qu’il est impossible de signifier cette notion dans un fichier, qui restera vide, une table de base de données, même si son cardinal est nul, conserve sa structure fortement typée, ses contraintes, …

Enfin toute ligne d’une table de base de données est lue comme l’unité de travail la plus simple, alors qu’on peut extraire seulement certains champs d’un enregistrement.

=> Une table n’est pas un tableau

Comme nous l’avons vu précédemment, la notion d’ordre en base de données n’existe pas, alors que dans un fichier ou flux, c’est tout à fait vrai.
En effet une table n’est pas accédée de façon séquentielle, et en ce sens l’utilisation de curseurs est un non-sens pour les traitements en base de données, puisqu’on peut associer à un curseur les mots NEXT, PREVIOUS, FIRST et LAST.
Notons au passage que les curseurs sont un héritage de ce bon vieux COBOL, qui permettait en outre de lire des fichier dits séquentiels.

Mais plus important que cela, c’est surtout les contraintes d’intégrité que l’on peut définir entre les tables d’une base de données, et qu’il n’est pas possible de définir dans un fichier, ou entre plusieurs fichiers.

Aussi, un fichier est attaché à sa méthode de stockage sur disque, ce qui n’est pas le cas d’une table de base de données, qui en fait totale abstraction.

Tout cela pour bien comprendre la différence fondamentale qu’il y a entre penser par ensembles, et penser séquentiellement.

ElSuket