列とフィールド：これらの用語を間違って使用していますか？
私はここで少し恥ずかしいと思います。私は常に「列」と「フィールド」という用語を完全に交換可能に使用してきたため、最近、技術的な議論で混乱が生じました。
しかし、これは正しくないこと、正しいことであると言われました（各用語をスプレッドシートの用語に変換し、データタイプやデータベースを有用にする他のすべてのものを無視します）。
- データベース列：スプレッドシート列と同様
- データベースレコード：スプレッドシートの行のように
- データベースフィールド：スプレッドシートの「セル」のような（特定の行の特定の列）
これは正しいですか？列とフィールドはそれよりも互換的に使用されると誓ったかもしれません。確かにそうだ。
したがって、しないテーブルにfieldsを追加し、テーブルにcolumnsを追加します。フィールドは、記録？
列とフィールドに関する他の考え？
編集：明確にするために、現在のコンテキストはMS SQL Serverです。 SQLサーバーの前の私の経歴はMS Accessでしたが、これらの用語の使用に影響を与える可能性があります。
リレーショナルデータベースの理論には、Wordフィールドの使用は含まれていません。 RDBMSの理論的基礎を提供する一連の論文を書いたE.F.コッド博士は、この用語を使用したことはありません。確認したい場合は、1970年の彼の独創的な論文 大規模な共有データバンクのデータのリレーショナルモデル を読むことができます。
ドメイン、テーブル、属性、キー、タプルなどの用語が使用されます。その理由の1つは、彼の論文がリレーショナル代数に大きく関係しており、特定の実装がデータベース内のテーブルを定義する方法がCoddによって重要であるとは考えられなかったことです。ベンダーは後でそれを具体化するでしょう。人々はまた、歴史的に、RDBMSはそれ以前の既存の階層データベースおよびネットワークデータベースから進化したものであり、RDMBSの内部の仕組みは依然としてデータの編成とストレージに関係する必要があることを理解する必要があります。
一般的に使用されており、グーグルを少し実行するだけで簡単に確認できます。フィールドと列are 同じこと。
DBase、Access、FilemakerなどのPCデータベースは通常、「列」ではなく「フィールド」を使用します。 「属性」は、同じ意味で使用できる別の用語です。
たとえば、テーブルに " field "を追加する際のMS Accessマニュアルへのリンクは次のとおりです。 MS Accessでは、「フィールド」が「列」と同等であることは明らかです。
DbaseとFilemaker Proについても同様です。
特定の行の特定の値を「フィールド」またはより適切には「フィールド値」として参照することがありますが、列または列の同等の概念を参照するときに「フィールド」を使用しません。人々は「フィールド」を長年さまざまなことを意味するために使用してきたため、これはある程度の混乱を引き起こす傾向があります。関係理論では、単一の原子値は「データム」と呼ばれます。
「フィールド」はリレーショナルデータベースの1つの値であり、列とは異なると誰かが述べた場合、それは彼らの意見です。「フィールド」はリレーショナルデータベースの一部ではないためです。それらは正しいものでも間違っているものでもありませんが、データベースの世界では、フィールドは列を意味するためによく使用されます。
そうは言っても、プロジェクトやチームは、混乱を避けるために、プロジェクト内で特定の用語をどのように使用したいのかを理解しなければならないことがよくあります。
間違いではありませんが、使用されている規則に従うだけか、「列」を優先してWordフィールドをまったく使用しないこともできます。リレーショナルデータベースでは、「テーブル」と「列」はDDLに存在する構成要素です。これらの用語を使用し、使用されていない、または明確に定義されていない「フィールド」は使用しないことをお勧めします。
古い SQL：92 は、日時アイテムのコンポーネントとしてfieldsを参照します。
「日時項目のフィールド」は、日時値を構成できるフィールドを指定します。日時値はこれらのフィールドのサブセットで構成されています
ここのフィールドは年、月などです... fieldという用語は、ドキュメントの残りの部分では他の意味を持たないようです。
新しいSQL：2003標準にはこれがあります：
列、フィールド、および属性
列、フィールド、および属性という用語は、それぞれ類似した方法で、テーブル、行タイプ、および構造化タイプの構造コンポーネントを指します。テーブルの構造は1つ以上の列で構成されるため、行タイプの構造も1つ以上のフィールドで構成され、構造化タイプの構造は1つ以上の属性で構成されます。列、フィールド、または属性に関係なく、すべての構造要素は、主に宣言された型とペアになった名前です。
以降：
fieldFはフィールド記述子によって記述されます。フィールド記述子には以下が含まれます。
—フィールドの名前。
— Fの宣言された型のデータ型記述子。
—単にそれを含む行タイプ内のFの序数位置。
これは、次のように定義される列と対照的です。
AcolumnCは列記述子によって記述されます。列記述子には以下が含まれます。
—列の名前。
—列の名前が実装依存の名前かどうか。
—列がドメインに基づいている場合は、そのドメインの名前。それ以外の場合は、Cの宣言された型のデータ型記述子。
-Cの値（ある場合）。
— Cのnull可能性の特性。
— Cを含むテーブル内でのCの順序位置。
... （もっと）
その後、再び、テーブルを導入するとき：
テーブルは、1つ以上の列を持つ行のコレクションです。行は、行タイプの値です。同じテーブルのすべての行の行タイプは同じです。 テーブル内のすべての行のi番目のフィールドの値は、テーブル内のその行のi番目の列の値です。行は、テーブルに挿入したり、テーブルから削除したりできるデータの最小単位です。
（強調鉱山）。これはあなたが質問で書いたことをサポートしているようです：特定の行の特定の列。
そして、ピンの頭の周りで何人の天使が踊ることができますか？
あなた自身を修正した人自身が修正することができます。
テーブル=リレーション
行=タプル
列=属性
ドメイン=データ型
リレーショナルデータベースのWikipediaのエントリ here を参照してください。
私は航空会社で働いていましたが、「フライト」という言葉は、パイロット/フライトアテンダント、エンジニア、マーケティングのどちらに話しているかに応じて、3つの異なる方法で使用できました。
- パイロット/アテンダント：「フライト」が基地から出入りしていた（つまり、離陸2回と着陸2回）
エンジニア：1つの離陸と1つの着陸は、テスト、修理、トレーニング（つまり、1つの空港から同じ空港に戻る）、または「レッグ」、つまり1つの空港から別の空港-通常、「民間人」がフライトと呼ぶもの「明日、飛行機に乗ります」）では、
マーケティング：契約に関連して、特定の空港から/への6か月（通常はオンシーズンまたはオフシーズン）の一連の「フライト」。
スプレッドシートの類推は、適度に技術的なスピーチ（関係代数の教授でない限り）の場合でも、99.99％のケースに十分対応できます。あなたを訂正した人は「whom」という言葉を正しく使っていますか？ 99.99％の人はそうではなく、それは本当に重要ではありません。
これは古い質問ですが、よく聞く質問です。私の見解は、データチームと開発チームとの関わりから来ています。開発者は間違いなく、画面に表示されるレコード内のフィールドを持ち、それらのフィールドには、特定の行を持つ列に頻繁にマップできるデータが含まれています。ただし、多くの場合、データへのアクセスに使用されるリレーショナルメソッドは、特定のフィールドの特定の画面に表示される結果を変更する可能性があります。
私が記録するのは、データが提供する現在の値の表現です。時間の経過とともに、これらの値は変化する可能性があり、おそらく変化するため、レコードも変化します。現在のデータとある時点のデータをサポートするデータは、一連のテーブルに簡単に格納できます。データ間の関係によって、常にレコードを構成する意味が決まります。
フィールドを導出するロジックは、時間の経過とともに変化する可能性があるものです。たとえば、ある従業員がスーザンジョーンズとして雇われ、彼女は2010年1月12日にストアマネージャーとしてビルアンダーソンに報告するストア＃101の販売員として雇われました。これは進歩的な会社であり、彼らはまた、各従業員に割り当てられたメンターを持っています。スーザンのメンターはメアリーフィリップスです。メアリーフィリップスは店長ですが、スーザンが勤務する店舗の地域マネージャーでもあります。2011年11月10日、スーザンは店長に昇格しました。ビルに何が起こったかはわかりませんが、スーザンが店長になりました。
名前、番号、入社日、役職、場所が記載された従業員の表があります。
メンターのテーブルには、メンターの従業員番号と、メンターをしている従業員と、メンター関係の開始と終了を説明する日付が含まれています。
地域の名前と割り当てられたマネージャー番号が記載された地域のテーブルがあります。
住所、説明、地域、マネージャー番号が記載された別の場所のテーブルがあります。
ストア情報を表示する画面には、ストアマネージャー用のフィールドがある場合があります。店長の値はデータベースフィールドではありませんが、時間の経過とともに変化する可能性のある計算可能な値です。また、人のマネージャーも変更できます。それをサポートするデータは引き続き列に格納されますが、列間の関係が変更され、特定の目的でアセンブルされるとフィールドになります。
私は一般に「フィールド」と「列」を交換可能に使用しますが、最近では「列」の傾向があります。 「フィールド」という言葉だけで「データ」を表すのは聞いたことがありません。また、「フィールド」または「列」を示す「属性」という用語を聞いたことがありません。列/フィールドは属性を持ち、たとえばFieldInfoクラスを介してアクセスできます。
「コラム」は単に用語の進化形だと思います。デスクトップDB（xBASE、MSAccess）は通常「フィールド」を使用します。 M204 「フィールド」を使用します。この「フィールド」の用語は、MSOfficeのxmlなどに取り入れられました。 Oracle（申し訳ありませんが、これ以上のリンクを投稿することはできません）とMSSQLのドキュメントでは、「フィールド」と「列」を一貫して使用しています。 Sybase（現在のSAP企業）は、ドキュメントで主に「列」を使用しますが、「フィールド」を使用することもあります。
ワークグループが条件に同意する限り、どちらの条件でもかまいません。それは「他の名前のバラ」症候群です。