Flat-file database
![]() | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|

A flat-file database is a tabular flat-file in which each record is semantically independent – can meaningfully be interpreted and manipulated independent of other records of the table. The term flat loosely refers to data that is record-based and sequential yet lacks more complicated aspects such as nesting, relationships and metadata (with the exception of column headers). Relationships can be inferred from the data, but the format does not provide special accommodations for relationships.
A flat-file is a file that contains flat data, and a flat-file database is a flat-file that can be used as a database.
Some data is flat yet not usable as a database in a meaningful way. For example, a file that lists the pixel colors of an image is not a database since the value of the data is wholistic. Manipulating the data like a database probably is not meaningful.
Format
A flat-file database may be stored as plain text or binary (not character encoded). When plain text, it is typically formatted as one record per line[2] either as delimiter-separated or fixed-width.
Delimiter-separated values
In delimiter-separated values files, the fields are separated by a character or string called the delimiter.
Common variants are comma-separated values (CSV) where the delimiter is a comma, tab-separated values (TSV) where the delimiter is the tab character), space-separated values and vertical-bar-separated values (delimiter is |
).
If the delimiter is allowed inside a field, there needs to be a way to distinguish delimiters characters or strings that are meant literally. For example, consider the sentence "If I have to, I'll do it myself.". To encode it in CSV, there needs to be a way to prevent the comma from splitting the field. Several strategies to prevent delimiter collision exist.
Fixed-width formats
With fixed-width formats, each field has a fixed length with extra spaces added as needed. The fixed lengths can be predefined and known ahead of time (i.e. stated in the format's specification), or parsed from a header.
With predefined lengths, fields are limited to a maximum length. The need for longer fields may appear sometime after the format is defined. Possible workarounds include abbreviating phrases, replacing values with links (e.g. a URI pointing to the value), and splitting a file into multiple files.
With delimiter-separated formats, determining the field boundaries requires finding the delimiters, which incurs some computational overhead. This is not needed for fixed-width formats. However, fixed-width formats can lead to unnecessarily large file sizes if fields tend to be shorter than the lengths reserved for them.
Declarative notation
Delimiters can be used alongside a notation stating the length of each field. For example, 5apple|9pineapple
specifies the length (5 and 9) of each field. This is called declarative notation. It has low overhead and trivially avoids delimiter collisions, but it is brittle when edited manually.
History
Herman Hollerith's work for the US Census Bureau first exercised in the 1890 United States census, involving data tabulated via hole punches in paper cards,[3] is sometimes considered the first computerized flat-file database, as it included no cards indexing other cards, or otherwise relating the individual cards to one another, save by their group membership.[citation needed]
In the 1980s, configurable flat-file database computer applications were popular on the IBM PC and the Macintosh. These programs were designed to make it easy for individuals to design and use their own databases, and were almost on par with word processors and spreadsheets in popularity.[citation needed] Examples of flat-file database software include early versions of FileMaker and the shareware PC-File and the popular dBase.
Flat-file databases are common and ubiquitous because they are easy to write and edit, and suit myriad purposes in an uncomplicated way.
Modern implementations
Linear stores of NoSQL data, JSON data, primitive spreadsheets (perhaps comma-separated or tab-delimited), and text files can all be seen as flat-file databases because they lack integrated indexes, built-in references between data elements, and complex data types. Programs to manage collections of books or appointments and address books may use single-purpose flat-file databases, storing and retrieving information from flat-files unadorned with indexes or pointing systems.
While a user can write a table of contents into a text file, the text file format itself does not include a concept of a table of contents. While a user may write "friends with Kathy" in the "Notes" section for John's contact information, this is interpreted by the user rather than a built-in feature of the database. When a database system begins to recognize and codify relationships between records, it begins to drift away from being "flat," and when it has a detailed system for describing types and hierarchical relationships, it is now too structured to be considered "flat."
Examples
Well known
In the context of Unix-like systems, the files /etc/passwd
and /etc/group
are flat-files.
Custom
The following illustrates typical elements of a flat-file database. The data is arranged as a table – a series of rows and columns
id name team 1 Amy Blues 2 Bob Reds 3 Chuck Blues 4 Richard Blues 5 Ethel Reds 6 Fred Blues 7 Gilly Blues 8 Hank Reds 9 Hank Blues
Points of interest:
- Field name header
The first row specifies the field names that are associated with the values of each row. The columns consist of an identifier (id), a person's name (name) and a team name (team).
- Field separation
Columns are separated by whitespace characters. This is also called indentation or "fixed-width" data formatting. Another common convention is to separate columns using one or more delimiter characters, such as a tab or comma.
- Data type
Each column may be restricted to a specific data type with restrictions usually enforced by convention.
- Relational algebra
Each row or record meets the standard definition of a tuple under relational algebra. This example depicts a series of 3-tuples.
- Database management system
Since the formal operations possible with a text file are usually more limited than desired, the text in the above example would ordinarily represent an intermediary state of the data prior to being transferred into a database management system.
See also
- Awk – Text processing programming language ; often used with a flat-file database
- Berkeley DB – Software library providing embedded database for key/value data
- Comma-separated values – Text file formats for tabular data
- Recutils – Toolset for using plain text files as a database
- Tab-separated values – Text file format for tabular data
References
- ^ "Data Integration Glossary" (PDF). U.S. Department of Transportation. August 2001. p. 10. Archived from the original (PDF) on March 20, 2009. Retrieved April 16, 2025.
- ^ Fowler, Glenn (1994), "cql: Flat-file database query language", WTEC'94: Proceedings of the USENIX Winter 1994 Technical Conference on USENIX Winter 1994 Technical Conference
- ^ Blodgett, John H.; Schultz, Claire K. (1969). "Herman hollerith: data processing pioneer". American Documentation. 20 (3): 221–226. doi:10.1002/asi.4630200307. ISSN 1936-6108.