[LUNI] file system limitations

[scott thomason]

On Wednesday 20 November 2002 06:14 pm, Erik Lickerman wrote:
> 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.

I don't know when you would _ever_ store one patient per database, 
unless you're mixin' and matchin' terms in ways I haven't heard over 
the last 20+ years. 

Regarding the data-members-of-objects angle...just "freeze" the darn 
thingy. All the the *DB libraries essentially provide you with a fast 
tool for doing key->value manipulations. You get to arbitrarily 
define the the content of "key" and "value". Say, for patient number 
0000001 as the "key", you serialize/freeze/insert-your-term-here the 
object members so you have one big glop of data, and it gets stored 
into "value". Simple. But that's just one way to skin the cat. Just 
trying to help explain Steve's concept.
---scott