Quelle est la différence entre un "enregistrement" et une "ligne" dans SQL Server?

56

Il y avait une question plutôt anodine sur l'ajout de dates et d'heures dans SQL Server qui a déclenché un débat taxonomique plutôt fascinant.

Alors, comment différencions-nous ces termes liés et comment les utilisons-nous correctement?

Rangée

Record

swasheck
la source
32
L'un propulse une embarcation, l'autre est utilisé par les sales hipsters pour jouer de la musique
billinkc
1
Un lié après le montre si clairement que cela est une question importante.
dezso
Notez que dans Postgres et Oracle, une seule ligne peut contenir plusieurs enregistrements ...
a_horse_with_no_name

Réponses:

69

Pour citer Joe Celko (vous pouvez non seulement trouver cette référence sur le Web et dans son entrée Wikipedia , mais vous la verrez même sur des T-shirts lors de certaines conférences):

Les lignes ne sont pas des enregistrements.

Beaucoup de gens le désignent comme un imbécile pédant qui aime simplement humilier et abuser verbalement des débutants, et j'admettrai que c'est comme ça qu'il se présente. Mais je l'ai aussi rencontré en personne - même partagé un repas avec lui - et je ne peux pas vous dire à quel point son personnage réel est différent de son site en ligne. Je l’ai même surpris une fois en train d’appeler des records de rangs, et il était très gêné ( histoire complète ici ).

J'ai porté ce t-shirt à la conférence PASS à Grapevine, Texas, en 2006

Quoi qu'il en soit, dites ce que vous voulez à propos du personnage en ligne du gars, mais il a écrit la norme , et le fait qu'une telle autorité dicte qu'il existe une distinction devrait vous dire quelque chose. Et autant il recule quand quelqu'un appelle un enregistrement, beaucoup de mes collègues le font aussi - qui sont également des experts du monde SQL Server. Et ceux d'entre nous dans ce camp croient qu'il a raison.

Par exemple, Itzik Ben-Gan, un gourou évident de SQL Server. Voici une citation de la toute première leçon de son kit de formation (Examen 70-461): Interrogation de Microsoft SQL Server 2012 :

En tant qu'exemple de termes incorrects dans T-SQL, les termes «champ» et «enregistrement» sont souvent utilisés pour désigner ce que T-SQL appelle respectivement «colonne» et «ligne». Les champs et les enregistrements sont physiques. Les champs sont ce que vous avez dans les interfaces utilisateur dans les applications clientes, et les enregistrements sont ce que vous avez dans les fichiers et les curseurs. Les tables sont logiques et comportent des lignes et des colonnes logiques.

Et, connaissant Itzik, si vous lui envoyez un e-mail ou si vous le bloquez lors d’une conférence, il vous répondra avec plaisir. Si vous appelez une ligne un enregistrement, à son avis, vous n'utilisez pas la terminologie correctement.

Maintenant, étant une industrie pleine de gens de toutes sortes, vous êtes susceptible de trouver du matériel (comme les articles sur les cibles technologiques postés dans une autre réponse) qui semblent faire des distinctions très subtiles entre les deux, et vous trouverez beaucoup de personnes dans l'industrie. Considérez-les de la même manière (je connais plusieurs personnes chez Microsoft et d’autres personnes comme Brent Ozar, qui l’appellera toujours comme un record). Cela ne les rend pas justes, c'est juste leur façon de voir les choses - ils voient la même chose de logique et physique (du moins dans ce contexte) et beaucoup pensent probablement que le reste d'entre nous ne sommes que des rétenteurs anaux qui passent trop de temps sur la sémantique.

Puisqu'aucun fournisseur ne peut dire "tu les appelleras {records | lignes}", nous aurons toujours affaire à cet argument, car il y aura toujours quelqu'un qui ne comprend pas la logique par rapport à la physique, ou qui a été enseigné différemment, ou venaient de Access ou de la programmation, etc. Comme certaines personnes le disent demain et d'autres disent le même, il y aura toujours une variété de personnes allant de "ils sont identiques" à "ils sont complètement différents "- et beaucoup de nuances entre les deux. Encore une fois, cela ne donne aucun droit, car personne ne peut être l'autorité suprême en la matière. Mais dans l'espace SQL Server, il y a certainement une majorité.


Cela dit, à mon humble avis, lorsque vous parlez de données qui se trouvent dans un tableau, vous appelez cela une ligne. Lorsque vous effectuez une insertion, vous insérez une ligne dans un tableau. Lorsque vous exécutez une mise à jour, vous mettez à jour une ligne qui se trouve dans une table. Et lorsque vous effectuez une opération SELECT, vous récupérez des lignes d'une table.

N'hésitez pas à appeler cela un enregistrement une fois que votre application en a pris possession. Mais ne vous fâchez pas si vous dites: "J'ai inséré un disque" et quelqu'un vous corrige.

Aaron Bertrand
la source
33

Microsoft a, à plusieurs endroits dans son organisation, prévu que le nom officiel du stockage de données sous forme de tableau par entrée de table (pour forger une définition taxonomique qui serve à mes propres fins) soit appelé une "emprise". Je soumets comme preuve ROW_NUMBER, ROWCOUNT, ROWVERSIONet la DataTable.Rowspropriété, où DataTableest une représentation C # d'un TSQL objet « de table ». Dans ce cas, les propriétés MSDN dans leur ensemble encouragent l'utilisation de rowréférence à une collection de données constituant une entrée dans une table. (notez que j'essaie d'éviter l'utilisation de "record" ou "row" pour définir ceci, c'est là le point de la question)

Cependant, le langage courant veut qu’une application traite des "enregistrements" d’utilisateur. Ce qui est unique dans un enregistrement qui peut ne pas être directement représenté par une seule ligne de stockage est le fait qu'un enregistrement peut avoir des sous-enregistrements. Certes, une table peut avoir des tables plusieurs-à-un liées, mais celles-ci ne sont pas stockées de manière contiguë, mais elles sont stockées de manière logique.

Ainsi, une ligne est la chose dans une table et un enregistrement est la chose avec laquelle le développeur travaille dans une utilisation pratique.

jcolebrand
la source
8
On peut soutenir que le ROW est l'entité logique, tandis que le RECORD est l'entité physique. Une ligne peut avoir plusieurs enregistrements: un dans l'index clusterisé, plusieurs dans les index NC. Une ligne qui ne rentre pas dans une page peut être fractionnée entre l'enregistrement de la page et les enregistrements de débordement dans le stockage SLOB. Une valeur BLOB d'un champ d'une ligne peut s'étendre sur plusieurs enregistrements TEXT du stockage BLOB. Une ligne dans un segment peut se composer d'un enregistrement de talon et d'un enregistrement en aval. Etc etc.
Remus Rusanu le
Ensuite, vous auriez complètement supprimé l’utilisation de l’enregistrement de mots du domaine de l’application, ou complètement brouillé les cartes, et nous auriez éloigné des termes définissables pour entrer dans le domaine de la conception théorique de la base de données et des détails de sa mise en œuvre. Vous soulevez de bons points, mais de la convention entre applications et bases de données, où 80% de nos lecteurs seront à l'aise, ma réponse est toujours valable.
jcolebrand
4
Je ne contredis pas votre réponse, je me suis peut-être trompée. J'ai seulement présenté la façon dont le moteur SQL lui-même perçoit les choses, la couche d'accès physique les appelant «enregistrements» par rapport à la couche de traitement de la requête (langage) qui gère les «lignes».
Remus Rusanu
Je vois. J'ai encore l'impression que cela brouille les eaux. Aucune infraction prise, je vous assure.
jcolebrand
31

Je viens de chercher dans le document "Technologies de l'information - Langages de base de données - SQL Partie 2: Fondation (SQL / Foundation)", qui définit la norme ANSI pour SQL telle qu'elle est mise en œuvre par tous les principaux SGBDR.

Le mot rowest principalement utilisé dans le document plusieurs centaines de fois, comme prévu.

Le mot a recordété utilisé uniquement pour décrire un enregistrement qui ressemble à un enregistrement utilisé dans Oracle PL / SQL (décrivant spécifiquement les types de données d'enregistrement ADA). 6 mentions dans le document.

Je pense que cela clarifie la question et répond aux divers arguments des deux côtés.


information additionnelle

Extrait d'une copie d'une (version préliminaire de la dernière norme SQL disponible gratuitement), disponible sur wiscorp.com (la page Normes SQL contient plusieurs autres versions et versions antérieures).

Une recherche dans 7IWD2-02-Foundation-2011-12.pdf , dont la date est le 2011-12-21, indique que la ligne de mot apparaît 2277 fois dans le document, tandis que le mot enregistrement n'apparaît que 21 fois, sous la forme du verbe "enregistrement" ou dans certaines annexes à la fin, dans les spécifications des correspondances de types de données pour les types de données SQL et les types de langage hôte (Ada, Pascal).

De plus, le même document a à la page 57 (c'est moi qui souligne):

4.15.1 Introduction aux tableaux

Ce paragraphe est modifié par le sous-paragraphe 4.10.1, «Introduction aux tableaux», de l'ISO / CEI 9075-9.

Une table est une collection de zéro ligne ou plus, chaque ligne étant une séquence d'une ou plusieurs valeurs de colonne. Le type le plus spécifique d'une ligne est un type de ligne. Chaque ligne d'une table donnée a le même type de ligne, appelé le type de ligne de cette table. La valeur du i-ème champ de chaque ligne d'une table est la valeur de la i-ème colonne de cette ligne dans la table. La ligne est la plus petite unité de données pouvant être insérée dans une table et supprimée d'une table.

Le degré d'une table et le degré de chacune de ses lignes sont le nombre de colonnes de cette table. Le nombre de lignes dans une table est sa cardinalité. Une table dont la cardinalité est 0 (zéro) est dite vide.

Une table est une table de base , une table dérivée ou une table transitoire .


Donc, en ce qui concerne les SGBD utilisant SQL:

Les lignes ne sont pas des enregistrements , les champs ne sont pas des colonnes, les tables ne sont pas des fichiers!

Philᵀᴹ
la source
14

Les bases de données relationnelles étant rarement utilisées isolément, afin de ne pas créer de confusion entre les autres parties des systèmes, je fais toujours référence aux tables, aux lignes et aux colonnes. Dans une application cliente, nous avons généralement d'autres constructions, notamment des archiveurs de données, des jeux de données, des datarows, des datatables, etc. .

Parfois, dans une conception de système, l'idée d'un "enregistrement" peut être utilisée pour désigner quelque chose de plus large qu'une simple ligne. C'est peut-être une rangée et c'est l'histoire. De même que lorsque nous parlons d’une ligne supprimée, nous pourrions parler d’une ligne simplement marquée comme supprimée avec une colonne ou "déplacée" vers une table supprimée (et pas simplement l’absence d’une ligne qui, en étant inexistante, est plutôt difficile à coincer). Il y a juste une utilisation plus variée du terme Record.

Les tableaux, les lignes et les colonnes sont la terminologie généralement utilisée pour désigner ces entités dans des bases de données relationnelles, y compris les documents et les travaux de Codd et Date. La plupart des professionnels des bases de données préfèrent cette terminologie, car elle est moins ambiguë.

Il n’ya généralement aucune ambiguïté lorsque l’on parle de lignes et de colonnes - d’autres personnes comprennent que vous parlez de la conception physique de la base de données sous-jacente et non de tout autre type d’artefacts d’une conception logique antérieure à la conception physique ou de toute entité système émergente ultérieure, comme des champs sur un objet. écran.

Cade Roux
la source
9

Bien que votre question est déjà très bien répondu. Je voudrais ajouter mes points aussi. Peut-être que vous trouvez cela utile jusqu'à un certain point. Aussi ma réponse n'est pas spécifique à SQL Server

Ces mots sont utilisés indifféremment.

 1          2         3              4 
--------------------------------------------------------------------
Row    =  Record  =  Tuple        =  Entity 

Column =  Field   =  Attribute    =  Attribute

table  =  File    =  Relation     =  Entity Types(or Entity Set)
  • 4 bonne terminologie à utiliser pour apprendre les modules ER
  • 3 utiliser quand modèle relationnel
  • 2 scène générale, DataBase books start with these terminologycar ils sont très utilisés dans la vie réelle, y compris dans les systèmes de fichiers.

Record est l'unité de base du système de stockage ayant une signification implicite. Dans les SGBD, le mot recordutilisé dans le chapitre décrit comment les tables de base de données sont stockées sur des blocs de disque. Dans le SGBD, un record-oriented file-systemest un système de fichiers dans lequel les fichiers sont stockés sous forme de collections d'enregistrements.

Grijesh Chauhan
la source
9

La langue continue d'évoluer. Il y a quelques décennies, les lettrés utilisaient des "indices" plutôt que des "index" plus simples. En passant aux "index", nous avons éliminé une complication inutile et rendu le langage plus utile. La nécessité de mémoriser un pluriel pour "index" était purement superficielle - cela ne nous aidait en aucune manière à communiquer. Ne vous y méprenez pas, il y avait des nazis de la grammaire qui aimaient corriger ceux qui étaient passés aux "index". Bien sûr, la grammaire nazie a perdu. C'est ainsi que le rasoir d'Occam élimine les détails inutiles si tout reste pertinent assez longtemps.

Soyons donc sereins - savoir que la différence entre les lignes et les enregistrements n’ajoute absolument rien à notre capacité de développer et de gérer des bases de données. Beaucoup d'excellents professionnels utilisent les lignes et les enregistrements de manière interchangeable, tout en développant des systèmes impressionnants. En tant que tel, le rasoir d'Occam devrait finalement éliminer la distinction et la prochaine génération devra apprendre un fait moins inutile. Si, bien sûr, SQL est toujours pertinent à ce moment-là.

AK
la source
5

Pour citer le livre de CJ Date "Une introduction aux systèmes de bases de données" "" Les lignes d'un tel tableau peuvent être considérées comme les enregistrements du fichier ... "

Donc, pour les bases de données, c'est Row.

Andrew Peterson
la source
4

Réponse courte :

  • Un enregistrement est une donnée stockée (ou collectée).
  • Une ligne est un enregistrement stocké linéairement.
  • Dans la mesure du possible, utilisez le terme plus spécifique.

Remarque: les tables stockent les enregistrements de manière linéaire et les requêtes renvoient les résultats de manière linéaire.

Soutien :

Définitions supplémentaires sur le Web:

  • SQL "rangée" ( 1 , 2 )
  • "Enregistrement" SQL ( 1 , 2 )
  • "record" ( 1 , 2 , 3 , 4 )
  • "rangée" ( 1 , voir aussi 2 , 3 , 4 )
  • Row vs Record sur StackOverflow ( 1 , 2 )

Il est à noter que les définitions SQL suivent généralement la définition anglaise.

Si vous avez une définition qui, selon vous, devrait figurer ici, veuillez l’ajouter aux commentaires.
Je m'intéresse particulièrement aux définitions du standard SQL ou à la documentation d'une implémentation.

La citation a été évoquée "Les lignes ne sont pas des enregistrements". Pris hors contexte, cela semblerait contredire mes affirmations précédentes (et celles de nombreux professionnels de bases de données). Mais si vous lisez tout le post ( 1 Search for the quote) de Joe Celko (aka --CELKO--), il devient évident que Joe Celko tente de corriger une idée fausse d'une personne qui, selon Joe Celko, découle de son " ... expérience en traitement de données avec les systèmes de fichiers traditionnels ... ". En bref, Joe Celko affirme que les lignes SQL ne fonctionnent pas de la même manière que les enregistrements d'autres systèmes. Joe Celko ne revendique pas le droit / privilège de définir un terme, il essaie de dissiper une mauvaise compréhension provoquée par l'application incorrecte des principes d'un modèle de stockage à un autre.

Trisped
la source
3
J'apprécie le travail et la pensée que vous avez mis dans cela. Je noterai que la différenciation de Celko est destinée à faire ressortir les différences entre le SGBDR et les systèmes de fichiers plats COBOL qui ont précédé le SGBDR. Ergo, il insiste sur la "ligne" en tant que partie d'un schéma SGBDR et d'un "enregistrement" en tant que partie constitutive d'un fichier à plat.
Swasheck