[BioSQL-l] Tables without a (composite) primary key
Peter
biopython at maubp.freeserve.co.uk
Thu Nov 6 12:37:42 UTC 2008
On Thu, Nov 6, 2008 at 12:23 PM, Raoul Jean Pierre Bonnal
<raoul.bonnal at itb.cnr.it> wrote:
>
> Dear Peter,
> I'm writing the wrapper for BioRuby using DataMapper an ORM (Active Record is
> similar).
Hi Raul,
I'm looking at a python based ORM to use with BioSQL.
[The existing Biopython BioSQL bridge uses raw SQL to turn the
sequences and features into Biopython objects - this all seems to work
fine, but it doesn't offer the full flexibility of an ORM framework.]
>
> I think we can cosider to move or branch BioSQL' schema to the approach
> suggested by this kind of ORMs, with a pk for every table named "id" and a
> table name in plural. Fk names are quite correct.
>
I don't think it makes sense to add a single primary key to many of
these tables (e.g. term_dbxref). The existing composite primary keys
seem fine (its just a shame some ORMs can't cope).
I was thinking the tables currently lacking any primary key could get
one (based on the current UNIQUE rule). So for example, the
taxon_name could use (taxon_id,name,name_class) as its primary key. I
don't know how big a change this would be - but superficially it looks
backwards compatible. This is why I was asking why they didn't have
PK in the first place.
>
> PS: DataMapper handles very well composite PK, much better tha ActiveRecord.
>
For python, currently Django and also I believe SQLObjects don't
support composite primary keys. I'll take a look at SQLAlchemy next
which should cope better.
Peter
More information about the BioSQL-l
mailing list