它是纯文本文件、二进制文件还是字符文件？有人可以解释平面文件的实际含义吗？
答案1
dirkt 询问上下文是正确的，但关于平面文件不是数据库或包含记录的说法是非常错误的。
平面文件数据库
在数据库的背景下，平面文件数据库满足以下条件：
- 它是一种数据库，在一个文件中仅包含一个表。
- 该表没有索引。
- 该结构不是关系型、层次型或网络型的。
- 该文件可以包括固定长度记录，其中字段由列位置表示，或者可变长度记录，其中记录和字段通过定界符彼此分隔。
在讨论这一问题时，人们可能会遇到文献中出现的基本顺序访问方法 (BSAM) 和排队顺序访问方法 (QSAM) 等术语。这与人们如何访问平面文件数据库有关。人们必须线性且顺序地读取和写入它们，因为这一概念不需要对记录进行排序，甚至不需要对其进行键控。
插入和删除涉及处理整个文件。平面文件数据库过去通常存储在有利于顺序访问的介质上，例如磁带，数据库更新有时会采取从输入磁带 A 和 B 读取并合并到输出磁带 C 的形式。（例如：A可能是今天开始的主文件，B 可能是今天的交易，C 可能是明天运行的主文件。）
日常平面文件数据库
你可能认为你不会再遇到这样的事情了，或者至少你不会在 Unix 和 Linux 上遇到它们。你也错了。以下是您遇到的一些平面文件数据库日常的：
- Linux 上的用户帐户数据库是平面文件的集合。
- 版本 7
/etc/passwd文件是单个表，具有可变长度记录，冒号字符作为字段分隔符，换行符作为记录分隔符。 /etc/group、/etc/shadow、 和 也是如此/etc/gshadow。
- 版本 7
- 该
/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涉及按顺序读取文件。没有索引，并且条目不按照用于搜索的键的顺序排序。查看用于搜索这些平面文件数据库的 C 库例程（例如gethostent()、getpwent()、getfsent()、getgrent()和getutxent()），除了我们稍后将介绍的例外情况外，您将看到顺序访问方法。 （各种getXbyY()例程都建立在这些例程之上。您会发现，它们只是调用顺序访问例程，直到找到匹配项为止。）
因此，在 BSD 上，实际的用户帐户数据库是不是平面文件数据库。它们是 Berkeley DB 文件，按 UID 和用户名索引。它们是由程序从平面文件数据库编译而来，该数据库存储在/etc/master.passwd,中pwd_mkdb。 C 库实际上读取/etc/pwd.dbor （如果可以的话）/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 狭隘视野时：这是一种误解，xBase 在dbf文件中存储以 ASCII 编码的字段内容这一事实有所帮助。人们过去常常谈论 xBase，它曾被吹捧为世界上最流行的数据库系统，作为“平面文件”系统，尽管他们实际上使用这个术语来反对“关系”或“面向对象”，并且以人们滥用“遗留”的方式错误地使用它“旧”。因此，“平面文件”系统“使用 ASCII”，但 dbf文件中确实有很多东西。不是解释为 ASCII 字符编码。）
进一步阅读
- 唐纳德·K·伯利森 (1998)。数据库对象模型内部。 CRC出版社。国际标准书号 9780849318078。
- 罗布·马蒂森 (1998)。了解数据库管理系统。麦格劳-希尔。 ISBN 9780070499997。
答案2
Unix 的 POSIX 标准中没有“平面文件”这样的东西，除了一次提到它：
系统邮箱的格式故意未指定。并非所有系统都将系统邮箱实现为平面文件，尤其是随着多媒体邮件消息的出现。有些系统邮箱可能是多个文件，有些则记录在数据库中。
在我的工作（生物信息学）中，“平面文件”是通常包含数据的纯文本 ASCII 文件，通常是 Fasta 格式（或衍生格式之一）的基因组数据。
这与存储在数据库或非 ASCII 文件（例如 BAM 或 CRAM 格式的文件）中的数据相反，尽管非 ASCII 文件也被某些人称为“平面文件”。
@ikkachu 提到的维基百科对“平面文件”的定义在这里并不完全合适，因为基因组数据通常数量巨大。将一个物种的整个 DNA 序列从平面文件读取到 RAM 中可能既慢又不必要，而且在许多情况下是不可能的。
生物信息学家似乎也宽松地使用术语“平面文件”任何他们使用的数据文件类型，即使数据文件的结构方式使其记录可能包含文件内的引用，例如 GTF/GFF 和 GeneBank 文件中的情况。
也许“平面文件”最通用的定义是包含数据的文件，如果必须对数据进行更改，则需要重写整个文件。我相信这也涵盖了一些二进制格式。
答案3
答案4
联合数据库技术 - 用于数据存储的平面文件，与绑定到程序哈希表的键/值对的 Perl SDBM 文件协同工作，用于固定长度记录偏移量（以字节为单位）的持久随机访问索引。这是一个 ISAM/NoSql 数据库系统实现。看： http://www.perlmonks.org/?node_id=1121222
存储在固定长度记录中的“文本”数据的平面文件数据库可以通过使用与程序哈希表相关的键/值对的 SDBM 二进制文件来设置即时随机访问，其中“值”是记录偏移量（以字节为单位）定位文件指针，其中键是：平面文件记录中包含的数据中的单个字段、部分字段或连接在一起的多个单个和/或部分字段。
社会保障号、贷款号或帐号都是可用作唯一键的字段的示例。
您可以为平面文件设置 SDBM 文件的多个索引，每个 SDBM 文件根据构成“键”的字段或部分字段包含一组不同的键/值对。可以通过向“键”添加序列 nbr 来使用具有 DUPLICATES 的备用索引。
可以使用单独的平面文件来保存与另一个平面文件中保存的每个单个父记录相关的多个子记录。示例：贷款平面文件（父级）和抵押品平面文件（儿童），其中儿童是每笔特定分期贷款的所有抵押品。
我使用 FLAT 文件每个 4GIG，SDBM 文件每个 2GIG。
数据可以在逻辑上隔离，以便于随机和顺序访问。示例：US_Census_2010_TX_A.dat 可以是一个平面文件，仅包含姓氏以字母“A”开头的德克萨斯州公民的数据。您可以有 50 个 STATE 子目录，每个子目录包含 26 个平面文件（一个用于 AZ）。批处理应用程序或用户界面可以通过了解平面文件和 SDBM 文件命名约定来访问正确的文件。
注意：类似的技术可以用来构建一个巨大的MS-ACCESS（实际上是MS-Jet“Red”引擎）数据库，通过ODBC访问，这样每个*.MDB文件只包含一个或多个后端表对象，并且每个 MDB 文件充当：所有 MDB 文件共有的单个表、表组或部分表。 MDB 文件本身并不是数据库——这是典型的。它们只是存储大量数据的容器，逻辑上隔离并建立索引，以优化顺序和随机访问。 MS-Access有自己的索引功能，因此这里不会使用SDBM进行索引。不需要 MS-Access 软件，因为 MDAC 和 ODBC 管理器实用程序出厂时安装在 Windows 7 上。使用 ODBC 管理器创建空 MDB 文件，并使用编程语言发出 SQL 语句来构建表和这些表的索引。