On Sat, Oct 27, 2012 at 06:27:38PM -0500, Jimmy Hess wrote:
> On 10/26/12, Clint Billedeaux <clint@fastbadge.com> wrote:
> > Actually, I'm using flat files and no database as a cost savings measure.
> > I would have been happy to build a database over time, but I got an offer
> > that was just too good to pass up.
>
> Well... a structured flat file is still a perfectly valid database, of
> course. Mbox and Maildir formats for storing e-mail are great
> examples of proven flatfile database usages.
> So depending on the application, and as long as you are just
> appending and not constantly rewriting the entire file or doing
> in-place replacements of records, it may be just the perfect thing to
> use.
>
> If you are storing application data in a structured flat file, it is
> still a database -- just not a very sophisticated one. Without a
> great deal of design and testing, for locking, integrity, repair,
> inherently single-user, and one issue in the flatfile driver could
> potentially violate the integrity of the entire dataset by damaging
> the structure of the flat file.
You can use the freeze/thaw capabilities of Perl to handle this, but
this doesn't give you efficient reading or indexing.
>
> So normally if the data is important and the dataset isn't transient in nature,
> something like sqlite3, BDB, or a free RDBM such as Postgres or MySQL
> is normally preferable
> :-)
The important question to ask is, will multiple clients be using this
file at any given time? If you're facing concurrent writes, then
you're going to have a very bad time unless you use something that is
meant to serialize or isolate these changes. Using a file to track
data is fine, but reinventing flat files is not a good idea.
For single client data files, I usually recommend sqlite.
Brett
>
>
> --
> -JH
> ___________________
> Nolug mailing list
> nolug@nolug.org
-- ___________________ Nolug mailing list nolug@nolug.orgReceived on 10/28/12
This archive was generated by hypermail 2.2.0 : 07/25/13 EDT