see what benefits/pitfalls there are and could be.
As one who moved from flat file DB's to many DB engines over the years, I'm pretty vocal about this to the point of "goin' medieval." :-)
There are modules and extensions for just about any programming language for accessing flat file databases that do all this for you, but it still has to be done via programming, as opposed to it being inherent in the database engines. The more you allow the database engine to work for you, the less you have to program.
Lack of automation. Nearly everything a database does for you,
you have to code yourself. Some really good examples:
- Field names. You need to maintain an array or have the first line of the database represent the field names so you can assign real values to columns (id, first name last name . . .
- Delimiting is automatic with databases, with flat files, you need to code it, which is not that simple at times. Are the fields quote qualified, if so, how do you deal with quotes in text? In a flat file, the newline is the "end of record" marker, how do you deal with newlines in fields?
- Sorting. Write a function to sort records by a field value, or do "order by fieldname desc." Which is going to make less work for you, and cost your client less?
- Data types. There are no preset datatypes in flat files, which means you have to program much more thoroughly and validate data manually.
Database operations. This, I think is the most burdensome of all.
- Searching. To match on a field, you must
-- read in the DB, line by line
-- split the line on the delimiters, store in array
-- locate the array index of the field
-- perform a strict equality match on the value, or a regular expression match
-- Not found? Move to the next line.
As opposed to
select * from table where field like '%$value%';
Which uses indexes to seek the matching records without reading in each and every record.
- Inserting/deleting/adding. Like the above, you need to read in the entire database line-by-line, store it in a second file or in memory until the matching record is found, REPLACE that line with new values (or skip it in delete,) then continue on to the end of the database, then overwrite the original with the new version. And pray nothing goes awry, even with file locking in place. Along the same lines . . .
No auto . . . ANYTHING. You have to create your own methods of generating unique record id's, there is no auto_increment. And in most cases this requires what? Yet another file to store the "current record number" in (or open the database, sort and get the highest number, increment it. Either way . . . )
Relational tables are a major pain to work with, but out of efficiency, you still have to try. There is no join. You have to write it, and figure out how to recreate the marvel of joins.
Functionality deficiencies. A brief look through some of the functions in the mySQL documentation, among which are the date and time formatting functions, will show you that you have to write programming that does all this wonderful stuff. What that adds up to is your flat file database application will have severe limitations and be extremely hard to maintain. Sometimes the slightest mods can require hours of work that would take a matter of minutes if your programming interfaces with a database.
In today's age there is no *good* reason to use flat file databases any more than good reasons for unwanted pregnancies, with the possible exception of old systems in place that were built on them (this site, for example.) Only the most severely disabled hosting services don't offer low cost database access and there is really no need to build new systems on flat file databases.
Unless you're experimenting, or don't expect growth and the needs will always be small. But on the Internet, that's seldom the case, we always hope to grow. :-)
