Colonne vs Champ: ai-je mal utilisé ces termes?
Je me sens un peu gêné ici, j'ai toujours utilisé les termes "colonne" et "champ" de manière complètement interchangeable, ce qui a récemment causé une certaine confusion dans une discussion technique.
On m'a dit, cependant, que ce n'était pas correct, qu'il devrait l'être (traduire chaque terme en terminologie de feuille de calcul, en ignorant les types de données et toutes les autres choses qui rendent les bases de données utiles):
- Colonne de base de données: comme une colonne de feuille de calcul
- Enregistrement de base de données: comme une ligne de feuille de calcul
- Champ de base de données: comme une "cellule" de feuille de calcul (une colonne spécifique d'une ligne spécifique)
Est-ce correct? J'aurais juré que la colonne et le champ sont utilisés de manière plus interchangeable que cela. Je l'ai certainement été.
Donc, nous ne pas ajoutons champs à une table, nous ajoutons colonnes à une table, et les champs ne sont pertinents que lorsque nous parlons de données dans un record?
D'autres réflexions sur la colonne par rapport au champ?
Edit: pour clarifier, le contexte actuel est MS SQL Server. Mon expérience avant SQL Server était MS Access, ce qui pourrait influencer mon utilisation de ces termes.
La théorie des bases de données relationnelles n'inclut pas l'utilisation du champ Word. Le Dr E.F. Codd, qui a écrit la série d'articles qui fournissent la base théorique des SGBDR, n'a jamais utilisé le terme. Vous pouvez lire son article fondateur de 1970 n modèle relationnel de données pour les grandes banques de données partagées si vous voulez vérifier.
Des termes tels que domaine, table, attribut, clé et tuple sont utilisés. Une des raisons à cela est que ses articles étaient largement concernés par l'algèbre relationnelle et que la manière dont une implémentation particulière définirait une table dans une base de données n'était pas considérée par Codd comme importante. Les vendeurs étofferaient cela plus tard. Les gens doivent également comprendre que, historiquement, les SGBDR ont évolué à partir des bases de données hiérarchiques et réseau existantes qui les ont précédées, ET le fonctionnement interne d'un RDMBS doit toujours se préoccuper de l'organisation et du stockage des données.
Dans l'utilisation courante, et vous pouvez facilement le vérifier en faisant simplement un peu de recherche sur Google, Champs et colonnes sont le même chose.
Les bases de données PC comme DBase, Access et Filemaker utilisent généralement "champ" au lieu de "colonne". "Attribut" est un autre terme qui peut être utilisé de manière interchangeable.
Par exemple, voici un lien vers le manuel MS Access sur l'ajout d'un " champ " à une table. Il est clair que dans MS Access un "champ" équivaut à une "colonne".
Il en va de même pour Dbase et Filemaker Pro.
Parfois, les gens se réfèrent à une valeur spécifique dans une ligne spécifique comme étant un "champ" ou plus correctement une "valeur de champ" mais cela ne rend pas l'utilisation de "champ" lorsqu'ils se réfère à une colonne ou à un concept équivalent de colonne incorrecte. Cela a tendance à créer un certain niveau de confusion, car les gens utilisent le mot "terrain" pour signifier différentes choses depuis de nombreuses années. Dans la théorie relationnelle - une seule valeur atomique est appelée "Datum".
Si quelqu'un a déclaré qu'un "champ" est une valeur dans une base de données relationnelle et pas la même chose qu'une colonne, c'est son opinion, car "champ" ne fait pas partie de la base de données relationnelle vernaculaire. Ils ne sont ni bons ni mauvais, cependant, dans le monde de la base de données, le champ est plus souvent utilisé pour signifier la colonne.
Cela dit, les projets et les équipes doivent souvent comprendre comment ils veulent utiliser une terminologie particulière dans le projet pour éviter toute confusion.
Vous ne vous trompez pas, mais vous pouvez également décider de simplement suivre la convention utilisée, ou d'éviter d'utiliser le champ Word complètement en faveur de "colonne". Avec les bases de données relationnelles, "Table" et "Colonne" sont les blocs de construction qui existent dans DDL et il est préférable d'utiliser simplement ces termes et d'éviter les "champs" qui ne sont pas utilisés, ni clairement définis.
L'ancien SQL: 92 fait référence à fields comme composants des éléments datetime:
"Champs dans les éléments datetime", spécifie les champs qui peuvent constituer une valeur date-heure; une valeur datetime est constituée d'un sous-ensemble de ces champs
Les champs ici sont année, mois, etc. ... et le terme field ne semble avoir aucune autre signification dans le reste du document.
La nouvelle norme SQL: 2003 a ceci:
Colonnes, champs et attributs
Les termes colonne, champ et attribut font référence aux composants structurels des tables, des types de lignes et des types structurés, respectivement, de manière analogue. Comme la structure d'une table se compose d'une ou plusieurs colonnes, la structure d'un type de ligne se compose également d'un ou plusieurs champs et celle d'un type structuré d'un ou de plusieurs attributs. Chaque élément structurel, qu'il s'agisse d'une colonne, d'un champ ou d'un attribut, est principalement un nom associé à un type déclaré.
et ensuite:
Un champ F est décrit par un descripteur de champ. Un descripteur de champ comprend:
- Le nom du champ.
- Le descripteur de type de données du type déclaré de F.
- La position ordinale de F dans le type de ligne qui le contient simplement.
Ce contraste avec la colonne, qui est définie comme:
Une colonne C est décrite par un descripteur de colonne. Un descripteur de colonne comprend:
- Le nom de la colonne.
- Indique si le nom de la colonne est un nom dépendant de l'implémentation.
- Si la colonne est basée sur un domaine, alors le nom de ce domaine; sinon, le descripteur de type de données du type déclaré de C.
- La valeur, le cas échéant, de C.
- La caractéristique de nullité de C.
- La position ordinale de C dans le tableau qui le contient.
... (et plus)
Puis plus tard, lors de l'introduction des tableaux:
Une table est une collection de lignes ayant une ou plusieurs colonnes. Une ligne est une valeur d'un type de ligne. Chaque ligne de la même table a le même type de ligne. La valeur du i-ème champ de chaque ligne d'un tableau est la valeur de la i-ème colonne de cette ligne du tableau . La ligne est la plus petite unité de données qui peut être insérée dans une table et supprimée d'une table.
(c'est moi qui souligne). Cela semble soutenir ce que vous avez écrit dans la question: une colonne spécifique d'une ligne spécifique.
Et combien d'anges peuvent danser autour de la tête d'une épingle?
La personne qui vous a corrigé pourrait elle-même l'être.
Table = Relation
Row = Tuple
Colonne = Attribut
Domaine = Type de données
Voir l'entrée Wikipedia sur les bases de données relationnelles ici .
J'ai travaillé pour une compagnie aérienne et le mot "vol" pouvait être utilisé de trois manières différentes selon que vous parliez à des pilotes/agents de bord, à des ingénieurs ou au marketing.
- pilotes/préposés: un "vol" était à destination et en provenance de la base (c'est-à-dire deux décollages et deux atterrissages),
ingénieurs: un décollage et un atterrissage, qui pourraient être des tests, des réparations, une formation (c'est-à-dire un aéroport de retour au même aéroport) ou une "étape", c'est-à-dire d'un aéroport à un autre - ce que les "civils" appellent normalement un vol, comme dans "Je prends mon vol de retour demain"),
marketing: une série de "vols" de six mois (généralement en saison ou hors saison) de/vers un aéroport donné dans le cadre d'un contrat.
L'analogie du tableur est plus que suffisante pour 99,99% des cas, même dans un discours raisonnablement technique (sauf si l'on est professeur d'algèbre relationnelle). La personne qui vous a corrigé utilise-t-elle correctement le mot "qui"? 99,99% des gens ne le font pas et cela n'a vraiment pas d'importance.
Je me rends donc compte que c'est une vieille question, mais c'est celle que j'entends souvent. Mon point de vue vient de l'implication de notre équipe de données avec notre équipe de développement. Les développeurs ont certainement des champs dans les enregistrements qui sont affichés sur les écrans et ces champs contiennent des données qui peuvent souvent être mappées à des colonnes avec des lignes spécifiques. Cependant, dans de nombreux cas, la méthode relationnelle utilisée pour accéder aux données peut modifier ce qui se retrouve sur un écran particulier dans un domaine particulier.
L'enregistrement est une représentation de la valeur actuelle fournie par les données. Au fil du temps, ces valeurs peuvent changer et changeront probablement, de sorte que l'enregistrement change également. Les données pour prendre en charge ce qu'elles sont maintenant et ce qu'elles étaient à un moment donné peuvent facilement être stockées dans un ensemble de tables. Les relations entre les données déterminent les significations qui composent l'enregistrement à un moment donné.
La logique qui dérive les champs est quelque chose qui peut changer avec le temps. Par exemple, une employée est embauchée en tant que Susan Jones et elle a été embauchée le 12/01/2010 en tant que vendeuse dans le magasin # 101 qui relève de Bill Anderson en tant que directeur de magasin. Cette entreprise progressiste a également un mentor assigné à chaque employé. Le mentor de Susan est Mary Phillips. Mary Phillips est gérante de magasin, mais elle est également gérante régionale du magasin où travaille Susan. Le 11/10/2011, Susan a été promue gérante de magasin. Nous ne savons pas ce qui est arrivé à Bill mais Susan est maintenant la gérante du magasin.
Nous avons un tableau des employés avec nom, numéro, date d'embauche, position et emplacement.
Nous avons un tableau des mentors avec les numéros d'employés des mentors et des employés qu'ils encadrent, ainsi que les dates décrivant le début et la fin de la relation de mentor.
Nous avons un tableau des régions avec un nom pour la région et un numéro de gestionnaire attribué.
Nous avons une autre table des emplacements avec adresse, description, région et numéro de gestionnaire.
L'écran qui affiche les informations du magasin peut avoir un champ pour le gestionnaire de magasin. La valeur du gestionnaire de magasin n'est pas un champ de base de données mais c'est une valeur calculable qui peut changer au fil du temps. Le manager d'une personne peut également changer. Les données qui le prennent en charge sont toujours stockées dans des colonnes, mais les relations entre les colonnes ont changé et lorsqu'elles sont assemblées dans un but spécifique, elles deviennent un champ.
J'utilise généralement "champ" et "colonne" de manière interchangeable, tendant plus récemment vers "colonne". Je n'ai cependant pas entendu le terme "champ" seul pour indiquer "données". Je n'ai pas non plus entendu le terme "attribut" pour indiquer "champ" ou "colonne". Une colonne/champ possède des attributs , accessibles via la classe FieldInfo par exemple.
Je pense que "colonne" est simplement une évolution de la terminologie. Les bases de données de bureau (xBASE, MSAccess) utilisent généralement "champ". M204 utilise "champ". Cette terminologie de "champ" a été importée dans MSOffice xml et autres. Les documents pour Oracle (cela ne me permettra plus de publier de liens, désolé) et MSSQL utilisent "champ" et "colonne" de manière interchangeable tout au long. Sybase (maintenant une société SAP) utilise principalement "colonne" mais parfois "champ" dans sa documentation.
Tant que votre groupe de travail est d'accord sur un terme, peu importe lequel. C'est un syndrome de "rose par un autre nom".