SQL Serverの「レコード」と「行」の違いは何ですか？
かなり魅力的な分類論的議論を引き起こした、かなり SQL Serverでの日付と時刻の追加に関する無害な質問 がありました。
では、これらの関連用語をどのように区別し、適切に使用するのでしょうか。
行
レコード
Joe Celkoを引用するには（この参照をWeb全体および 彼のWikipediaのエントリ で見つけることができるだけでなく、一部の会議ではTシャツでも参照できます）：
行はレコードではありません。
多くの人々は、初心者を謙虚に、そして口頭で虐待するのが好きなだけの独断的なジャークとして彼を指摘します、そして私はそれが彼が遭遇する方法であることを認めます。しかし、私は彼と直接会ったこともあり-食事を彼と共有したことさえありました-彼の実際のペルソナが彼のオンラインのフロントとどのように異なるかをあなたに言うことはできません。私は彼が行レコードを呼び出すのを一度もキャッチしました、そして彼は非常に恥ずかしかったです（ ここで完全な裏話 ）。
いずれにせよ、その男のオンラインキャラクターについてどう思うか言いますが、彼が標準を書きました、そしてそのような当局が存在することを指示しているという事実区別はあなたに何かを伝える必要があります。そして、誰かが行をレコードと呼ぶときに彼がうんざりするのと同じくらい、SQL Serverの世界の専門家でもある私の同僚の多くもそうです。そして、そのキャンプにいる私たちの人々は、彼が正しいと信じています。
たとえば、明らかにSQL Serverの第一人者であるItzik Ben-Ganです。これは、彼の最初のレッスンの引用です トレーニングキット（試験70-461）：Microsoft SQL Server 2012のクエリ ：
T-SQLの不適切な用語の例として、人々はしばしば「フィールド」および「レコード」という用語を使用して、T-SQLがそれぞれ「列」および「行」と呼ぶものを指します。フィールドとレコードは物理的です。フィールドはクライアントアプリケーションのユーザーインターフェイスにあるものであり、レコードはファイルとカーソルにあるものです。テーブルは論理的で、論理的な行と列があります。
そして、イツィクを知っていれば、彼に電子メールを送信したり、会議で彼を追い詰めたりすると、喜んであなたに同じことを教えてくれます。行をレコードと呼ぶ場合、彼の意見では、用語を正しく使用していません。
現在、あらゆる種類の人々でいっぱいの業界であるため、2つを非常に微妙に区別しているように見える資料（別の回答に投稿された技術ターゲット記事など）を見つける可能性が高く、業界には多くの人々がいますそれらを同じものと見なしてください（Microsoftの何人か、そして常にレコードと呼ぶBrent Ozarのような他の人々を知っています）。それは彼らを正しくしていません、それは彼らのそれの見方です-彼らは論理と物理を同じように（少なくともこの文脈では）見ています、そして彼らの多くはおそらく私たちの残りの人はあまりに多くの時間を費やしている肛門の保持者だと思っていますセマンティクス。
どのベンダーも「あなたはそれらを{レコード|行}と呼ぶ」とは言えないので、私たちは永遠にこの議論に対処します。論理対物理を取得しない、または異なる方法で教えられた人が常にいるからです。アクセスやプログラミングの背景などから来ました。ある人がtomay-toと言うのと同じように、他の人がtomah-toと言うのと同じように、「同じ」から「まったく違う」まで、さまざまな人が常にいます"-との間の多くの色合い。繰り返しになりますが、これはそれらのいずれも正しくしません。なぜなら、これに対する最終的な権威はだれもいないからです。しかし、SQL Serverの領域では、間違いなく多数が存在します。
そうは言っても、私は、テーブル内のデータについて話しているとき、それを行と呼びます。挿入を実行すると、テーブルに行が挿入されます。更新を実行すると、テーブル内の行が更新されます。 SELECTを実行すると、テーブルから行が取得されます。
アプリケーションに保持されたら、自由にレコードと呼んでください。しかし、「レコードを挿入しました」と言っても怒らないでください。誰かがあなたを修正します。
Microsoftは、組織内のいくつかの場所で、テーブルエントリごとの表形式のデータストレージの公式名（自分の目的を満たす分類学的定義を作り出すため）を "ROW"と呼んでいます。証拠として提出ROW_NUMBER、ROWCOUNT、ROWVERSIONおよびDataTable.Rowsプロパティ。ここで、DataTableは、TSQL「テーブル」オブジェクトのC＃表現です。この場合、MSDNプロパティは全体として、rowを使用して、テーブル内の1つのエントリであるデータのコレクションを参照することを推奨します。 （これを定義するために「レコード」または「行」の使用を避けようとしていることに注意してください、それが問題のポイントです）
ただし、専門用語では、アプリケーションはユーザーの「レコード」を扱います。単一のストレージ行で直接表すことができないレコードのユニークな点は、レコードがサブレコードを持つことができるという事実です。確かに、テーブルには多対1のテーブルを関連付けることができますが、それらは連続して格納されていませんが、論理的に関連付けられて格納されています。
つまり、行はテーブル内のものであり、レコードは開発者が実際に使用して作業するものです。
すべての主要なRDBMSで実装されているSQLのANSI標準を定義しているドキュメント「情報技術—データベース言語— SQLパート2：基盤（SQL/Foundation）」を検索したところです。
Word rowは、主にドキュメント全体で予想どおり数百回使用されています。
Word recordは、Oracle PL/SQLで使用されるレコード（特にADAレコードのデータ型を記述する）に類似したレコードを記述するためにのみ使用されていました。文書内の6件の言及。
これでこの問題は解決し、双方のさまざまな議論に答えると思います。
追加情報
Wiscorp.comにあるSQL標準（無料で入手できる最新のドラフトバージョン）SQL標準のコピーから（SQL標準のページには、他にもいくつかの古いバージョンとリビジョンがあります）。
7IWD2-02-Foundation-2011-12.pdfを日付2011-12-21で検索すると、単語rowが表示されますWord recordが文書内で2277回出現するが、SQLデータ型とホスト言語のデータ型の対応の仕様では、動詞「record」として、または最後にいくつかの付録として21回しか出現しないタイプ（Ada、Pascal）。
さらに、同じ文書の57ページに（私の強調）があります。
4.15.1テーブルの概要
この節は、ISO/IEC 9075-9の4.10.1節「はじめに」で変更されています。
テーブルは0個以上の行のコレクションですここで、各行は1つ以上の列の値のシーケンスです。 行の最も具体的なタイプは行タイプです。特定のテーブルのすべてのrowは、そのテーブルの行タイプと呼ばれる同じ行タイプを持っています。テーブル内のすべてのrowのi番目のフィールドの値は、テーブル内のそのrowのi番目の列の値です。 行は、テーブルに挿入し、テーブルから削除できるデータの最小単位です。
テーブルの次数、およびその各行の次数は、そのテーブルの列の数です。テーブル内の行の数は、そのカーディナリティです。カーディナリティが0（ゼロ）のテーブルは空であるといいます。
tableは、ベーステーブル、派生テーブル、または一時テーブルのいずれかです。
SQLを使用するDBMSに関する限り、
行はレコードではありません、フィールドは列ではなく、テーブルはファイルではありません！
リレーショナルデータベースが単独で使用されることはほとんどないため、システムの他の部分間の混乱を避けるために、常にテーブルと行と列を参照します。クライアントアプリケーションでは、通常、データリーダー、データセット、データ行、データテーブルなどの他の構成要素があります。たとえば、「フィールド」は画面上のデータ入力によく使用され、PascalはCの構造体に似たRecordデータ型を持っています。
システム設計では、「レコード」の概念が単一行よりも広いものを意味するために使用される場合があります。行かもしれないし、それは歴史だ。削除された行について説明するときと同じように、列で削除済みとしてマークされた行、または削除されたテーブルに「移動」された行を意味する場合があります（存在しないため、行が存在しないだけでなく、突き止める）。用語「レコード」の使用法はより多様です。
テーブル、行、および列は、リレーショナルデータベースでこれらのエンティティを参照するために一般的に受け入れられている用語であり、CoddとDateによる論文や研究を含みます。データベースの専門家の大半は、あいまいさがないため、この用語を好みます。
行と列について話すとき、あいまいさは通常ありません。他の人は、基礎となるデータベースの物理設計について話していることを理解しており、物理設計の前の論理設計からのその他の種類のアーティファクトや、フィールドのような後で出現するシステムエンティティについては理解していません。画面。
言語は進化し続けています。数十年前、文盲の人々は、単純な「インデックス」ではなく「インデックス」を使用していました。 「インデックス」に切り替えたので、不要な複雑化を排除し、言語をより使いやすくしました。 「インデックス」の複数形を記憶する必要性は純粋なオーバーヘッドでした-それは決してコミュニケーションに役立ちませんでした。間違いなく、「インデックス」に切り替えたものを修正するのを楽しんだ文法ナチスがかつてあった。もちろん、ナチスの文法は失われました。このようにして、Occamのかみそりは、全体が十分に関連性を保っていれば、無駄な詳細を排除します。
簡単に説明しましょう。行とレコードの違いを知っていても、データベースの開発と保守の能力にはまったく何の影響もありません。多くの優秀な専門家が行とレコードを互換的に使用しながら、素晴らしいシステムを開発しています。そのため、Occamのカミソリは最終的に区別を排除する必要があり、次世代は役に立たない事実を1つ少なく学ばなければならないでしょう。もちろん、その時点でSQLがまだ関連している場合。
あなたの質問はすでに非常によく答えられていますが。ポイントも付け加えたいです。 あなたがそれがいくつかの拡張まで役立つと思うかもしれません。また、私の答えはSQL Serverに固有のものではありません
これらの単語は同じ意味で使用されます。
1 2 3 4
--------------------------------------------------------------------
Row = Record = Tuple = Entity
Column = Field = Attribute = Attribute
table = File = Relation = Entity Types(or Entity Set)
- ERモジュールを学ぶ際に役立つ4つの用語
- 3リレーショナルモデルの使用
- 2一般的なシーン、
DataBase books start with these terminologyなぜなら、これらはファイルシステムでも、実生活で非常に一般的に使用されているからです。
レコードは、暗黙的な意味を持つストレージシステムの基本単位です。 DBMSの章の「record」という言葉は、データベーステーブルがディスクブロックにどのように格納されるかを説明しています。 DBMSではrecord-oriented file-systemは、ファイルがレコードのコレクションとして格納されるファイルシステムです。
C.J. Dateの本「データベースシステム入門」を引用するには "このようなテーブルの行は、ファイルのレコードと考えることができます..."
したがって、データベースの場合はRowです。
短い答え：
- レコードは、格納（または収集）されたデータの一部です。
- 行は、線形に格納されたレコードです。
- 可能な限り、より具体的な用語を使用してください。
注：テーブルはレコードを線形に格納し、クエリは結果を線形に返します
サポート：
ウェブ全体からの追加の定義：
- SQL "行"（ 1 、 2 ）
- SQL "レコード"（ 1 、 2 ）
- "レコード"（ 1 、 2 、、 4 ）
- "行"（ 1 、 2 、、 4 も参照）
- StackOverflowの行とレコード（ 1 、 2 ）
SQLの定義は一般的に英語の定義に従っていることに注意してください。
ここにあると思われる定義がある場合は、コメントに追加してください。
SQL標準の定義または実装のドキュメントに特に興味があります。
「行はレコードではない」という見積もりが出されました。文脈から外すと、これは私の以前の主張（および多くのデータベース専門家の主張）と矛盾するように思えます。しかし、ジョーセルコ（別名--CELKO--）による投稿全体（ 1 引用を検索）を読むと、ジョーセルコがジョーの個人の誤解を修正しようとしていることが明らかになります。 Celkoは、その人物の「...従来のファイルシステムでのデータ処理の経歴...」に由来すると考えています。つまり、Joe Celkoは、SQL行は他のシステムのレコードと同じようには機能しないと述べています。 Joe Celkoは、用語を定義する権利/特権を主張していません。彼は、あるストレージモデルを別のストレージモデルに誤って適用することによってもたらされる見落としを解消しようとしています。