[LUNI] file system limitations

[Jirsa, Jeff]

Correct me if I'm wrong, but I thought BerkleyDb (and variants) is just a
glorified hash table on disk; just key/data pairs.

If I want to get a list of all the patients who had tonsillitis, I would
have to check the record of EVERY record in the database.  If you are going
to queries like this, you may seriously want to look at using MySQL or 
PostgreSQL.

Either way, marshaling the data in and out of objects will have to be done
for the DBM or a RDBM.  IMHO, I can't believe that the time marshaling the 
data will be a noticeable performance problem for your application.

-----Original Message-----
From: Erik Lickerman [mailto:elickerman at ameritech.net]
Sent: Wednesday, November 20, 2002 6:15 PM
To: luni at luni.org
Subject: RE: [LUNI] file system limitations


I'm not sure I understand the question.  BerkelyDb, and every other kind of
database I know of, ultimately store data in files on disk.  The only issue
is whether you partition your data by known characteristics, such as one
patient per database, or whether you put it all in one large database and
let the database handle things for you.

Also I am not storing text.  I am storing the data-members of objects, some
of which are text.

As for your last point, if I understand it correctly, you are saying that
given that BerkeleyDb has a B-Tree mechanism built in, what is the point to
using a similar mechanism from the filesystem.  My answer is, that I suppose
they are functionally equivalent except when it comes to moving patient
charts around geographically.  If you have the patient chart tree handled at
the BerkeleyDb level, you are responsible for writing such an administrative
tool yourself, while if you keep each patient's info in a separate
directory, I think you could leverage any of several existing filesystem
admin tools to do it.

Erik

-----Original Message-----
From: luni-admin at luni.org [mailto:luni-admin at luni.org]On Behalf Of
Steven Lembark
Sent: Wednesday, November 20, 2002 2:53 PM
To: luni at luni.org
Subject: RE: [LUNI] file system limitations




-- Erik Lickerman <elickerman at ameritech.net>

> Gentlemen:
>
> There is no call to remove the kid gloves.
>
> I think this is an interesting discussion.  For my application I wouldn't
> expect to take a huge performance hit from the journaling because most of
> my file requests are reads.  The writes tend to come all at once when a
> note is signed.  As one of you pointed out, I need to make sure
> everything gets flushed to disk.  BTW, I didn't mean to be misleading but
> I am using a database, BerkeleyDb.  I'm just not using a relational one.

Then why bother with files? You can store (nearly) arbitrary
text easily in DB -- with tree lookup to boot. In that case
just use the BerkeleyDB module with a Perl tied hash and 99%
of the code is already done for you.



--
Steven Lembark                               2930 W. Palmer
Workhorse Computing                       Chicago, IL 60647
                                            +1 800 762 1582
______________________________________________________________________
Linux Users Of Northern Illinois - Technical Discussion
luni at luni.org
http://luni.org/mailman/listinfo/luni

______________________________________________________________________
Linux Users Of Northern Illinois - Technical Discussion 
luni at luni.org
http://luni.org/mailman/listinfo/luni