<p>Informed options needed about the merits of flat file database.  I'm considering using a flat file database scheme to manage data for a custom blog.  It would be deployed on Linux OS variant and written in Java.  </p>

<p>What are the possible negatives or positives regarding performance for reading and writing of both articles and comments?</p>

<p>Would article retrieval crap out because of it being a flat file rather than a RDBMS if it were to get slash-doted? (Wishful thinking)</p>

<p>I'm not against using a RDBMS, just asking the community their opinion on the viability of such a software architecture scheme.</p>

<p><strong>Follow Up:</strong>
In the case of this question I would see “Flat file == file system–based” For example each blog entry and its accompanying metadata would be in a single file. Making for many files organized by date structure of the file folders (blogs\testblog2\2008\12\01) == 12/01/2008</p>

(answer copied and modified from
here
)
I would advise against using a flat file for anything besides read-only access, because then you'd have to deal with concurrency issues like making sure only one process is writing to the file at once. Instead, I recommend
SQLite
, a fully functional SQL database that's stored in a file. SQLite already has built-in concurrency, so you don't have to worry about things like file locking, and it's really fast for reads.
If, however, you are doing lots of database changes, it's best to do them all at once inside a
transaction
. This will only write the changes to the file once, as opposed to every time an change query is issued. This dramatically increases the speed of doing multiple changes.
When a change query is issued, whether it's inside a tranasction or not, the whole database is locked until that query finishes. This means that extremely large transactions could adversely affect the performance of other processes because they must wait for the transaction to finish before they can access the database. In practice, I haven't found this to be that noticeable, but it's always good practice to try to minimize the number of database modifying queries you issue, and it's certainly faster then trying to use a flat file.