In most cases, you would want your
database to support various types of relations; such databases, particularly if
designed correctly, can dramatically improve the speed of data retrieval as
well as being easier to maintain. Ideally, you will want to avoid the
replication of data within a database to keep a high level of integrity,
otherwise changes to one field will have to be made manually to those that are
related.
While several flat-files can be
combined in such a way as to be able to emulate some of the behaviours of a
relational database, it can prove to be slower in practice. A single connection
to a relational database can access all the tables within that database;
whereas a flat file implementation of the same data would result in a new file
open operation for each table.
All the sorting for flat-file
databases need to be done at the script level. Relational databases have
functions that can sort and filter the data so the results that are sent to the
script are pretty much what you need to work with. It is often quicker to sort
the results before they are returned to the script than to have them sorted via
a script, few scripting languages are designed to filter data effectively and
so the more functions a database supports, the less work a script has to do.
If you are only working with a small
amount of data that is rarely updated then a full blown relational database
solution can be considered overkill. Flat-file databases are not as scaleable
as the relational model, so if you are looking for a suitable database for more
frequent and heavy use then a relational database is probably more suitable.
