dirktが文脈を尋ねるのは正しいですが、フラットファイルがデータベースではないか、レコードが含まれていると言うのは非常に間違っています。

フラットファイルデータベース

データベースの文脈では、フラットファイルデータベース次の条件：

• ファイルに1つのテーブルのみを含むデータベース。
• このテーブルにはインデックスがありません。
• 構造はリレーショナル、階層型、ネットワーク型ではありません。
• ファイルには、フィールドが列位置として表示される固定長レコード、またはレコードとフィールドが区切り文字で区切られた可変長レコードを含めることができます。

この問題を議論するとき、文献に登場する基本順次アクセス方式（BSAM）とキュー順次アクセス方式（QSAM）という用語に触れることができます。これは、人々がフラットファイルデータベースにアクセスする方法に関連しています。この概念では、レコードをソートしたりキーを入力したりする必要がないため、線形で順次読み書きする必要があります。

挿入と削除には完全なファイル処理が含まれます。テープなどのシーケンシャルアクセスを容易にするメディアに保存されているフラットファイルデータベースとデータベースの更新は、時々入力テープAとBから読み取られ、出力テープCにマージされるようになりました。 （例：Aは今日開始するマスターファイル、Bは今日のトランザクション、Cは明日実行されるマスターファイルです。）

日常的なフラットファイルデータベース

これは再び起こらないと思うかもしれませんし、少なくともUnixとLinuxでは起こらないと思うかもしれません。あなたも間違っています。以下は、利用可能ないくつかのフラットファイルデータベースです。毎日:

• Linuxのユーザーアカウントデータベースはフラットファイルの集まりです。
  • バージョン7/etc/passwdファイルは、可変長レコード、フィールド区切り文字としてコロン文字、レコード区切り文字で改行文字を含む単一の表です。
  • /etc/group、、/etc/shadowにも同様です/etc/gshadow。
• ファイル/etc/fstabは、可変長レコード、フィールド区切り文字で改行ではなく空白文字、レコード区切り文字で改行文字を含む単一の表です。ファイルシステムテーブル- 名前にぴったりです。
  • /etc/services、、、、、、および同様です。/etc/crontab/etc/phones/etc/ttys/etc/hosts/etc/protocols
• ログインデータベース（Linux /run/utmp;、、FreeBSDなど）は、固定長レコードがあり、フィールドまたはレコード区切り文字がなく、フィールドが列位置として表示されるフラットファイルデータベースです。/var/log/wtmp/run/utx.active/var/log/utx.lastlogin/var/log/utx.log

上記の可変長レコードデータベースでレコードの挿入および削除を実行するためにファイル全体を読み取ってから、ファイル全体を再作成しないと考えることもできます。カーソルを移動し、行の削除と挿入を実行します。しかし、あなたはテキストエディタが提供するファイルI / O全体を無視しています。それ自体実際にそうしたときファイルのロードと保存。ファイル自体に対する実際のアプローチは、フラットファイルデータベース方式です。

フラットファイルではなく、日常的なデータベース

このようなフラットファイルデータベースは、シーケンシャルアクセス以外のものを望む場合にパフォーマンスが低下するフラットファイルデータベースの例である。ホスト/etc/hostsまたはユーザーアカウントの検索には、/etc/passwdファイルを順番に読み取る操作が含まれます。インデックスはなく、アイテムは検索に使用されたキーの順序で並べ替えられません。これらのフラットファイルデータベース（たとえばgethostent()、、、、、getpwent()などgetfsent()）getgrent()をgetutxent()取得するためのCライブラリルーチンを見ると、後で処理される例外を除いて順次アクセス方法が表示されます。 （さまざまなgetXbyY()ルーチンがこれらのルーチンの上に構築されています。一致するものが見つかるまで順次アクセスルーチンを呼び出すだけです。）

したがって、BSDでは、実際のユーザーアカウントデータベースは次のようになります。いいえフラットファイルデータベース。 UIDとユーザー名で索引付けされたBerkeley DBファイル。 .NETファイル/etc/master.passwdに保存されているフラットファイルデータベースのプログラムによってコンパイルされますpwd_mkdb。 Cライブラリは実際に/etc/pwd.dbまたは（可能な場合）を読み込みます/etc/spwd.db。

BSD「機能データベース」ソースファイル構造（たとえば/etc/gettytab、、、、/etc/login.confおよび/etc/termcap）は真のフラットファイルではありません。 （/etc/login.conf.dbコンパイルされたファイル構造は/etc/termcap.dbおよびにありますが、決してそうではありません。）レコードには参照として他のレコードを含めることができ、特定のレコードのすべてのフィールドを見つけるために従う必要があるチェーンを形成します。実際、コンパイラはcap_mkdbまさにそのようなことをします。

フラットファイルは「ASCIIテキスト」ではありません。

ASCIIは、ファイル、グループ、レコード、および単位（フィールドなど）区切り文字の特定の制御文字を定義します。 UnicesとLinuxでは主に使用されず、代わりにスペースTAB、LFコロンなどの文字を使用します。

人々は時々「フラットファイルデータベースには単純なASCIIテキストが含まれています」と言います。上記の例のいくつかを見ると、これは事実ではないことは明らかです。これは、特定の一般的なタイプの可変長レコードフラットファイルデータベースの場合にのみ当てはまります。しかし、UnixやLinuxシステムでも広く使われているログインデータベースもフラットファイルデータベースですが、その中のさまざまなフィールドは確かにフラットファイルデータベースです。いいえASCII文字エンコーディングとして解釈されます。

（より広い世界を見てUnix / Linuxトンネルビジョンを超えて見ると、これはdbfxBaseがASCIIでエンコードされたフィールドの内容をファイルに保存するという事実から生じる誤解です。人々はxBaseについて話していました。世界で最も人気のあるものです。データベースシステムは「フラットファイル」システムですが、実際には「リレーショナル」または「オブジェクト指向」という用語を使用しており、人々が「レガシー」を誤用したのと同じ方法で「古い」システムです。使用していますが、 dbfファイルには実際に多くのコンテンツがあります。いいえASCII文字エンコーディングとして解釈されます。 )

追加読書

• Burleson、ドナルドK.（1998）。データベースオブジェクトモデルの内部。 CRCプレス。 ISBN 9780849318078.
• マティソン、ロブ（1998）。データベース管理システムについて学ぶ。マクグロヒル。 ISBN 9780070499997.

Unix用のPOSIX規格には、以下の言及を除いて「フラットファイル」というものはありません。

システムメールボックスの形式は意図的に指定されていません。すべてのシステムがシステムメールボックスをフラットファイルとして実装するわけではなく、特にマルチメディアメールメッセージの出現のためにさらにそうです。一部のシステムメールボックスは複数のファイルで構成できますが、他のシステムメールボックスはデータベースに書き込まれます。

私の仕事（生物情報学）では、「フラットファイル」は通常通常、Fasta形式（または派生型のいずれか）のゲノムデータであるデータを含むプレーンテキストASCIIファイルです。

これは、データベースまたは非ASCIIファイル（BAMやCRAM形式のファイルなど）に保存されているデータとは対照的です。ただし、非ASCIIファイルは、一部では「フラットファイル」とも呼ばれます。

@ikkachuが言及した「フラットファイル」のWikipedia定義は、ゲノムデータのサイズが大きいため、ここでは完全には適切ではありません。フラットファイルからRAMに種の完全なDNA配列を読み取ることは遅くて不要で、ほとんどの場合不可能です。

生物情報学者は「フラットファイル」という用語を緩やかに使用しているようです。どのGTF / GFFおよびGeneBankファイルの場合など、レコードがファイル内に参照を含めることができるようにデータファイルが構成されていても、それらが使用するデータファイルの種類。

おそらく、「フラットファイル」の最も一般的な定義は次のとおりです。データを変更する必要がある場合は、ファイル全体を書き換える必要があるデータを含むファイル。私はこれがいくつかのバイナリ形式にも当てはまると思います。

おそらくこれには良い答えはないでしょう、そしてその用語が正しい意味を持っているかどうか疑問です。

一般に、これはいくつかの構造を持ち、それ自体が役に立つことを意味します（必須インデックスがないなど）、ここから定義が分かり始めます。

FOLDOCの定義明らかに、バイナリデータとは反対の（ASCII）テキストを含むフラットファイルです。 (ソースなし)ウィキペディアの定義その部分だけを修正すると、更新になるよりは「全体的にメモリから読み書きする必要がある」と見られます。行の長さはさまざまで連続して保存されるため、一般的なテキストファイルはこの定義に適しています。したがって、ほとんどの変更により、後続のファイルの場所が変更されます。

私にとっては、データベースのテキストダンプは「フラットファイル」と見なされますが、バイナリファイルについてはわかりません。 YMMV。

連合データベース技術 - データ保存用のフラットファイル、プログラムハッシュテーブルにバインドされたキー/値ペアのPerl SDBMファイルと連携して、固定長レコードオフセット（バイト）の継続的なランダム化のためのアクセスインデックス。これはISAM / NoSqlデータベースシステムの実装です。望むより： http://www.perlmonks.org/?node_id=1121222

固定長レコードに「テキスト」データを格納するフラットファイルデータベースは、プログラムハッシュテーブルに関連付けられたキーと値のペアのSDBMバイナリを使用して即時ランダムアクセス用に設定できます。ここで、「値」はレコードオフセット（バイト単位）です。 ）キーが単一フィールド、部分フィールド、またはフラットファイルレコードに含まれるデータにまとめられている複数の単一フィールドおよび/または部分フィールドであるファイルポインタを見つけます。

住民登録番号、ローン番号、または口座番号は、一意のキーとして使用できるフィールドの例です。

フラットファイルにSDBMファイルの複数のインデックスを設定できます。各SDBMファイルには、「キー」を構成するフィールドまたはフィールドの一部に基づいて異なるキー/値ペアのセットが含まれています。 DUPLICATESを持つ代替インデックスは、「キー」にnbrシーケンスを追加することで使用できます。

別々のフラットファイルを使用して、異なるフラットファイルに保存された各単一の親レコードに関連する複数の子レコードを保存できます。例：ローンフラットファイル（親）と担保フラットファイル（サブ）。ここで、子はすべて特定の分割払いのための担保です。

私はそれぞれ4GIGのFLATファイルを使用し、それぞれ2GIGのSDBMファイルを使用します。

簡単にランダムアクセスとシーケンシャルアクセスのためにデータを論理的に分離できます。例：US_Census_2010_TX_A.datは、姓が文字「A」で始まるテキサス市民のデータのみを含むフラットファイルです。それぞれ26個のフラットファイル（AZ用1個）を含む50個のSTATEサブディレクトリを持つことができます。バッチアプリケーションまたはユーザーインターフェースは、フラットファイルとSDBMファイルの命名規則を理解して正しいファイルにアクセスできます。

注：同様の技術を使用して、ODBCを介してアクセスされる巨大なMS-ACCESS（実際にはMS-Jet "Red"エンジン）データベースを構築できます。したがって、各* .MDBファイルには1つ以上のバックエンドテーブルオブジェクトのみが含まれ、各MDBはファイルがすべてのMDBファイルに共通の単一テーブル、テーブルグループ、または部分テーブルとして機能します。 MDBファイル自体はデータベースではありません。これは一般的です。これは、シーケンシャルアクセスとランダムアクセスを最適化するために論理的に分離されインデックス化された大量のデータを格納する単純なコンテナです。 MS-Accessには独自のインデックス機能があるため、ここではSDBMをインデックスに使用しません。 MDAC および ODBC 管理ユーティリティは Windows 7 に既定でインストールされているため、MS-Access ソフトウェアは必要ありません。 ODBCマネージャを使用して空のMDBファイルを作成し、プログラミング言語を使用してSQL文を実行して、そのテーブルのテーブルとインデックスを作成します。