[Biojava-l] SQL-backed persistent Biojava sequence/feature objects

[Thomas Down]

On Mon, Jul 30, 2001 at 01:48:57PM +0100, Ewan Birney wrote:
>
> > in BioJava.  For instance, a Java-centric schema could get
> > away with tricks like serializing any datatypes it didn't
> > explicitly understand (I'm thinking particularly of
> > Annotation-bundle data here).  That sort of thing could probably
> > be piggy-backed onto the BPDB schema as an `optional extra'
> > without too much trouble.
> 
> There are similar things on the Bioperl side as well -- ;) I am all for a
> series of DDL files of increasing complications to allow the schema to
> grow in complexity around a stable core, and not against "shove it
> in" methods of raw language serialisation and/or hacky tag-value sets
> (xml-styleee) for the more "just store this object" type problems. Of
> course, Biojava and Bioperl wont interoperate on these data types, but we
> will be able to let each project represent all its bells and whistles
> but having a common core.

This should piggy-back in quite easily.  Just a BLOB of data,
and a little tag for which serialization style is in use.

> > A rather bigger problem is hierarchical features, which I'd
> > say were quite important if we're aiming for `persistant
> > BioJava' rather than a more general database system.  This
> > definitely does mean a new schema.  And quite possibly
> > stored proceedures on the server (or something similar) to
> > keep the performance good -- at least given my past experiences
> > with hierarchical data in SQL.
> > 
> 
> Bioperl has a half-used heirerachical scheme for features which is now in
> limbo due to our split locations. In other words, if biojava wanted to add
> heirarchy into the schema I would be fine too see that happen and could
> provide mappings to bioperl.

Okay, I thought that this would be the main hard-to-resolve
problem, but perhaps not.

(Actually, I was pondering a bit over lunch and in principle
it's possibly to piggyback hierarchy onto a flat feature model,
simply by putting the parent-child relationships into their
own table, and making that optional.  It's not quite the
conventional way of doing it, but it could work pretty well...
So long as you're happy with `optional extras' being used
alongside BPDB, it's probably worth a try!)

David, have you looked at the BPDB schema?  How welll do you
think it meets your needs?

   Thomas.