From: Doug Sutherland (wearable_at_earthlink.net)
Date: 2002-03-06 06:44:57
Hi Andreas,
> A bf-practicioner or researcher may want to track the progress
> of dozens of patients over some fifty sessions or more and
> reate summaries and statistics. Even a single user training by
> himself could benefit from this. For a single session, it would
> not make much sense, I agree. And I see where you are coming
> from - it is difficult to install an SQL-server on an embedded
> device - although there is an embedded version of MySQL.
My comment has nothing to do with embedded, I am using both
compactflash and laptop (IDE) hard drives, I have plenty of
storage and ram, that's not the issue. If the above is a
desireable feature, I really think it makes sense to have
a separate tool for that. In other words, write flat files
for the current session, load into database after. This will
make things more efficient on the feedback side, by using
less resources, just a thought ...
> Ok, we're not there yet, so right now it may sound like
> overkill, though I like to think it could mean less work
> and working on a higher level of abstraction.
The file access stuff will not be difficult.
> Since samples and perhaps aggregate data are streamed to
> regular files, the database would only help to keep track
> of that data and not use many CPU cycles during sessions.
> Look at it as a more convenient way of saving and managing
> configuration data, session scripts or whatever, than
> regular files.
It may make some sense to consider analysis features as a
separate runtime, invokable from the main program, but
kept separate for efficiency and low resource usage. I am
not against databases, I love them, but keeping in mind
that we want fast application response, fast user feedback,
and good performance on a wide variety of machines, this
is why I would argue to making analyis a separate feature,
with the database functions.
> A raw file system using directory trees, like the one you
> propose, could do exactly the same thing but would need
> much more work going into developing management tools.
Managing the raw files for just feedback should not be
any more difficult than storing in a database. We could
then have routines to load any files into database tables
and do all kinds of analysis. But I suggest that we worry
about good feedback first, with only the minimal of
necessary features to acheive that. If we try to include
every possible feature initially we may be making a very
common mistake.
-- Doug
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST