Wow. Never thought of such a simple design. Leveraging off the existing file system is a great idea. Ultimately, however, I wouldn't do it that way for two main reasons:
1. The overhead of opening/creating, read/writing, and closing a file with each record access is huge when many records are accessed.
2. I've already written component file systems and would be able to leverage off of pre-existing / pre-tested code. (I suppose I'd have to find it though...)
Great idea.
Given the ubiquity of SQL databases, and the fact that you get keyed or indexed access for free, I think I would go that way. I see it looking like this:
CREATE TABLE my_table (
numeric_key bigint,
string_key character varying(100),
short_data character varying(1000),
long_data text
);
numeric_key and string_key would both be indexed. You would use the one that made the most sense on a record by record basis. short_data would be used for data that fits in that space. long_data for the larger stuff.
I have APL code that converts arbitrary nested arrays to/from plain strings.
I feel strongly that a data persist mechanism is an absolutely necessity. This would be an easy and portable solution.
Thanks.
Blake