Talk:Flat file

An ASCII text file usually contains the contents of a database table saved in plain text format. Each row is one record from the database. The flat file may or may not contain a file delimiter which is used to separate data fields within the flat file. Common delimiters that are used are tabs, commas and pipes.

Article rewrite

This article is in serious need of a (complete) rewrite. It is unstructured, confusing, jumps back and forth, contains offtopic information, is full of weasel words and contains a lot of unreferenced material (not just the flagged sentences).

If I can find the time, I will completely rewrite the article in the next days. If somebody objects, please say so. Adrianwn (talk) 08:49, 10 August 2008 (UTC)

On second thought, it is probably more appropriate to merge this article into the corresponding section of flat file database. Adrianwn (talk) 10:28, 10 August 2008 (UTC)

I did some research, and academic as well as non-academic sources use the term "flat file" to refer exclusively to text files, usually with one record per line. Since the article does not cite any sources, it must be assumed that "flat file" never refers to non-text files (counterexamples?).

It seems that there are two main uses for flat files:

• flat file databases (includes "real" databases as well as semi-structured storage of information, e.g. a list of enzymes); this is the only use of flat file in the academic literature
• configuration files

The latter hardly qualifies for an article, while the former better fits into the flat file database-article, especially since a cleanup of this article would shorten it to stub-length:

• removal of weasely statements: "Some definitions...", "Often each field...", "Flat files are often described...", etc.
• removal of claims without sources to back them up: "Fixed length records were often traditionally 80 bytes in length", "Flat files are still widely used for data transmission", "and require significanty more processing to locate the data", and many more
• removal of bogus statements: "knowing how many records fit on each track or sector of the particular physical disk on which they reside" (hardly any application reads files by directly accessing physical addresses), "support high performance operations" (what are "high performance operations"?), ...
• off-topic information: "An ETL system will generally sort the input file before submitting it to the database's bulk loader, in order to reduce total elapsed time"

Apparently this topic does not have enough potential for a full-blown article, so I suggest merging it with flat file database#Flat files and making this page a redirect to that section. Adrianwn (talk) 17:11, 13 August 2008 (UTC)

There is a difference between a "flat file" and a "flat file database", namely, as stated in the first sentence, a flat file does not have an indexing field, while a flat file database does, but the data contained therein is not normalised. In the example given on the flat file database#Flat files page, normalising the data would result in a second table (teams) containing the values 'Reds' and 'Blues' with probable indices of 1 and 2, and these indices would appear as foreign key entries in the 'names' database. The key difference between a 'flat file' (ff) and a 'flat file database' (ffd) is that in a ffd, you can discover that 'Ethel supports Reds' by requesting the software to find all data on the index '5', or the name 'Ethel', or the team 'Reds', while in a ff it would be necessary to read all of every record until an exact match for the criteria is met. (For amusement, put an old-school COBOL programmer in a room with an SQL programmer, give them a problem, and watch the sparks fly). Therefore, I don't think merging the articles would be appropriate...Gabhala (talk) 23:41, 13 August 2008 (UTC)

"There is a difference between a "flat file" and a "flat file database"" - I never disputed this; after all, I don't want to merge Flat file with Flat file database, but with one specific section of the latter - this section even carries the same name. Furthermore, a file of a flat file database is a flat file itself (hence the name), even if the first column is interpreted as an index. The section Flat file database#Flat files is already general (not database-specific), respectively can be slightly expanded, so that flat file can be made a redirect to this section. Another reason is that once you remove all the cruft from this article (see my rationale above), it would be stub-length at best (because there simply doesn't exist enough encyclopedic material relating to flat files).

"For amusement, put an old-school COBOL programmer in a room with an SQL programmer, give them a problem, and watch the sparks fly" - what's your point?

Adrianwn (talk) 09:36, 14 August 2008 (UTC)

Since there were no more objections, I went ahead and merged. The result is small, but there really isn't much encyclopedic content you can write about flat files... Adrianwn (talk) 08:06, 22 August 2008 (UTC)

Wikiproject Computing

I have removed the WikiProject tag, as this article is either a redirect or deleted. If you oppose, please restore the tag. Thank you, fahadsadah (talk,contribs) 16:05, 30 March 2009 (UTC)

This should not redirect to Flat File Database

Was this supposed to redirect to a small section within FFD page? Maybe that section got deleted?

It doesn't make sense to redirect this to anything about databases. Flat files can be used without the existence of a database.

The term basically means "unstructured file" as opposed to one with a structure that is enforced by the file system.

This describes a file system that enforces structure: http://en.wikipedia.org/wiki/Record-oriented_filesystem

This file system has examples of structured files: http://en.wikipedia.org/wiki/Virtual_Storage_Access_Method

In IBM's VSAM all but one of the file types are non-flat.

So if you want to use a flat file on VSAM you would create a Linear Data Set LDS.

This is IBM's way of saying there is no structure: "All LDS bytes are data bytes. Logical records must be blocked and deblocked by the application program. Logical records are transparent from VSAM’s point of view. In a sense, a LDS is a non-VSAM file with some of the VSAM facilities, such as the use of IDCAMS and VSAM specific information in the catalog." --http://kmlinux.fjfi.cvut.cz/~oberhtom/mainframe/redbooks/vsam-demyst.pdf

I don't know if you'll find the term "flat file" defined in published academic works. It might just be a colloquial term used (and misused) in the IT industry.

You also often hear people talk about "flattening" data structures when they are describing serialization or marshalling. Its the same concept.

But you don't get paid the big bucks for using simple words like "flat" and "flatten" in your books. :) — Preceding unsigned comment added by 24.107.129.55 (talk) 16:33, 24 August 2013 (UTC)