Quelle est la différence entre un "enregistrement" et une "ligne" dans SQL Server?
Il y avait plutôt question inoffensive sur l'ajout de dates et d'heures dans SQL Server qui a déclenché un débat taxonomique plutôt fascinant.
Alors, comment pouvons-nous différencier ces termes connexes et comment les utiliser correctement?
Ligne
Enregistrement
Pour citer Joe Celko (non seulement vous pouvez trouver cette référence partout 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'admets que c'est ainsi qu'il se présente. Mais je l'ai également rencontré en personne - j'ai 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 front en ligne. Je l'ai même surpris une fois en train d'appeler des enregistrements de lignes, et il était très embarrassé ( histoire complète ici ).
Dans tous les cas, dites ce que vous voulez du personnage en ligne du gars, mais il a écrit la norme , et le fait qu'une telle autorité dicte qu'il existe un la distinction devrait vous dire quelque chose. Et autant qu'il grince des dents lorsque quelqu'un appelle une ligne un record, autant de mes collègues - qui sont également des experts dans le 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 :
Comme exemple de termes incorrects dans T-SQL, les gens utilisent souvent les termes "champ" et "enregistrement" pour faire référence à 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 coincez 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 trouverez probablement du matériel (comme les articles cibles technologiques publiés dans une autre réponse) qui semblent faire des distinctions très subtiles entre les deux, et vous trouverez de nombreuses personnes dans l'industrie considérez-les comme les mêmes (je connais plusieurs personnes chez Microsoft, et d'autres comme Brent Ozar, qui l'appellera toujours un record). Cela ne leur donne pas raison, c'est juste leur façon de voir les choses - ils considèrent logique et physique comme les mêmes (au moins dans ce contexte) et beaucoup d'entre eux pensent probablement que le reste d'entre nous ne sont que des rétentifs anaux qui passent trop de temps sur la sémantique.
Puisqu'aucun fournisseur ne peut dire "tu les appelleras {enregistrements | lignes}", nous aurons toujours affaire à cet argument, car il y aura toujours quelqu'un qui ne comprend pas la logique contre le physique, ou qui a été enseigné différemment, ou est venu de milieux d'accès ou de programmation, etc. "- et de nombreuses nuances entre les deux. Encore une fois, cela ne fait aucun droit, car personne ne peut être l'autorité ultime à cet égard. Mais dans l'espace SQL Server, il y a définitivement une majorité.
Cela dit, à mon humble avis, lorsque vous parlez de données qui sont dans un tableau, vous l'appelez 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 un tableau. Et lorsque vous effectuez un SELECT, vous récupérez des lignes d'une table.
N'hésitez pas à l'appeler un enregistrement une fois que votre application l'a en main. Mais ne vous fâchez pas si vous dites: "J'ai inséré un enregistrement" et que quelqu'un vous corrige.
Microsoft a plusieurs endroits dans leur organisation à condition que le nom officiel pour le stockage tabulaire des données par entrée de table (pour inventer une définition taxonomique qui serve mon propre but) soit appelé "ROW". Je soumets comme preuve ROW_NUMBER, ROWCOUNT, ROWVERSION et le DataTable.Rows propriété, où DataTable est une représentation C # d'un objet "table" TSQL. Dans ce cas, les propriétés MSDN dans leur ensemble encouragent l'utilisation de row pour faire référence à une collection de données qui est une entrée dans une table. (notez que j'essaye d'éviter l'utilisation de "record" ou "row" pour définir cela, c'est là le point de la question)
Cependant, le langage est qu'une application traite des "enregistrements" d'utilisateurs. Un élément unique d'un enregistrement qui ne peut 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 un tableau, et un enregistrement est la chose avec laquelle le développeur travaille en pratique.
Je viens de parcourir 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'implémentée par tous les principaux SGBDR.
Le Word row est utilisé principalement dans le document plusieurs centaines de fois, comme prévu.
Le mot record était uniquement utilisé pour décrire un enregistrement qui s'apparente à 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 cette question et répond aux différents arguments des deux côtés.
Informations supplémentaires
À partir d'une copie d'une (version préliminaire de la dernière norme SQL disponible gratuitement), qui peut être trouvée sur wiscorp.com (la page Normes SQL contient plusieurs autres versions et révisions plus anciennes).
La recherche dans le 7IWD2-02-Foundation-2011-12.pdf, avec une date 2011-12-21 révèle que le mot ligne apparaît 2277 fois dans le document alors que le mot enregistrement n'apparaît que 21 fois, soit sous la forme du verbe "enregistrer" ou à la fin dans certaines annexes, dans les spécifications des correspondances de types de données pour les types de données SQL et le langage hôte types (Ada, Pascal).
De plus, le même document a à la page 57 (je souligne):
4.15.1 Introduction aux tableaux
Ce paragraphe est modifié par le paragraphe 4.10.1, "Introduction aux tableaux", dans l'ISO/CEI 9075-9.
ne table est une collection de zéro ou plusieurs lignes où chaque ligne est une séquence d'une ou plusieurs valeurs de colonne. Le type le plus spécifique d'un 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 dans un tableau est la valeur de la i-ème colonne de ce ligne dans le 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.
Le degré d'une table, et le degré de chacune de ses lignes, est 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.
A table est soit table de base, a table dérivée, soit table transitoire.
En ce qui concerne les SGBD qui utilisent SQL:
Les lignes ne sont pas des enregistrements, les champs ne sont pas des colonnes, les tableaux ne sont pas des fichiers!
Étant donné que les bases de données relationnelles sont rarement utilisées isolément, afin d'éviter toute confusion entre d'autres parties des systèmes, je fais toujours référence aux tables et aux lignes et colonnes. Dans les applications clientes, nous avons généralement d'autres constructions, y compris des lecteurs de données, des ensembles de données, des lignes de données, des tables de données, etc. - par exemple, "field" est souvent utilisé pour la saisie de données à l'écran et Pascal a un type de données Record qui est similaire à une structure en C .
Parfois, dans une conception de système, l'idée d'un "enregistrement" peut être utilisée pour signifier quelque chose de plus large qu'une seule ligne. Ce pourrait être une rangée et c'est de l'histoire. Tout comme lorsque nous parlons d'une ligne supprimée, nous pourrions signifier une ligne qui est 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 n'existant pas, 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 une terminologie généralement acceptée pour faire référence à ces entités dans les bases de données relationnelles, y compris les articles et les travaux de Codd et Date, et la majorité des professionnels des bases de données préfèrent cette terminologie car elle est plus claire.
Il n'y a 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 avant la conception physique ou de toute entité système émergente ultérieure comme des champs sur un écran.
La langue continue d'évoluer. Il y a quelques décennies, les lettrés utilisaient des "indices" au lieu de simples "indices". 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 une pure surcharge - cela ne nous a d'aucune façon aidé à communiquer. Ne vous y trompez pas, il y avait des nazis de grammaire qui aimaient corriger ceux qui passaient aux "index". Bien sûr, les nazis de grammaire ont perdu. C'est ainsi que le rasoir d'Occam élimine les détails inutiles si le tout reste pertinent suffisamment longtemps.
Alors, allons-y doucement - sachant la différence entre les lignes et les enregistrements n'ajoute absolument rien à notre capacité à développer et à maintenir des bases de données. De nombreux 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 éventuellement éliminer la distinction, et la prochaine génération devra apprendre un fait inutile de moins. Si, bien sûr, SQL est toujours pertinent à ce moment-là.
Bien que votre question ait déjà très bien répondu. Je voudrais également ajouter mes points. Peut-être trouverez-vous cela utile jusqu'à un certain point. De plus, ma réponse n'est pas spécifique à SQL Server
Ces mots sont utilisés de manière interchangeable.
1 2 3 4
--------------------------------------------------------------------
Row = Record = Tuple = Entity
Column = Field = Attribute = Attribute
table = File = Relation = Entity Types(or Entity Set)
- 4 terminologie bonne à utiliser lorsque nous apprenons les modules ER
- 3 utiliser lorsque le modèle relationnel
- 2 scène générale,
DataBase books start with these terminologyparce que ceux-ci sont couramment utilisés par les gens dans la vie réelle, également dans le système de fichiers.
Record est l'unité de base du système de stockage qui a une signification implicite. Dans le SGBD, l'utilisation de Word record 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-system est un système de fichiers où les fichiers sont stockés en tant que collections d'enregistrements.
Pour citer le livre de C.J. Date "An Introduction to Database Systems" "(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.
Réponse courte :
- Un enregistrement est un morceau de données stockées (ou collectées).
- 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
Prise en charge :
Définitions supplémentaires sur le Web:
- "Ligne" SQL ( 1 , 2 )
- "Enregistrement" SQL ( 1 , 2 )
- "enregistrement" ( 1 , 2 , , 4 )
- "ligne" ( 1 , voir aussi 2 , , 4 )
- Ligne vs enregistrement 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 devrait figurer ici, veuillez l'ajouter aux commentaires.
Je suis particulièrement intéressé par les 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 semble contredire mes affirmations précédentes (et celles de nombreux professionnels des bases de données). Mais, si vous lisez l'intégralité du message ( 1 Rechercher la citation) de Joe Celko (alias --CELKO--), il devient clair que Joe Celko essaie de corriger une idée fausse d'un individu que Joe Celko croit provenir de "... l'expérience de la personne dans le traitement des données avec les systèmes de fichiers traditionnels ...". En bref, Joe Celko dit que les lignes SQL ne fonctionnent pas de la même manière que les enregistrements dans d'autres systèmes. Joe Celko ne revendique pas le droit/privilège de définir un terme, il essaie de clarifier une mauvaise compréhension provoquée par une application incorrecte des principes d'un modèle de stockage à un autre.