Learning how to manipulate text files to do my bidding as far back as 1987, on a Commodore 64, makes me prefer them over databases. In recent years, people have harped at me to use databases instead of flat files (another term for plain text files) — for various reasons.

Flat files work best when used in a single-user environment. Only one process accesses the file(s) at one time. Logging applications work this way. Problems start occurring when you start using them in multi-user environments. A hit counter, for example, can be easily corrupted when one user's process opens a file and another user's process opens the same file and the file gets updated by the second instance before the first and then closed. It sounds confusing, but I've seen it happen many times. File locking schemes work, but not always.

Databases normally work better for multi-user environments, especially when web servers and database servers are kept separate. But what happens when a database server goes down, even for a minute? You have problems like I had recently. Within a span of less than a month, my hosting company made errors that prevented my website from operating. One period was for 3+ hours and the other for about an hour. The web server was working fine. The database server was down. A website that relies on a database to operate is worthless without the database, isn't it? I figure, if I had been using flat files, I would have been okay. Ah, but the problems with flat files remain, right?

I believe flat files can be made just as reliable as databases. The trick is to validate the data every step of the way, including file sizes. It would be complicated for anyone but experienced programmers, but I know it can be done. I plan to prove it for myself in the near future.