[BioSQL-l] location type

[Thomas Down]

On Tue, Oct 15, 2002 at 01:52:43AM -0700, Hilmar Lapp wrote:
>
> I agree you can try to optimize this in software using various 
> approaches. My problem with this is it necessitates specialized code 
> for query construction, query processing, and object construction, 
> as you say. With a strict separation of schema code from object code 
> this is somewhat tedious, bloats the code, makes the feature and 
> location adaptors break the otherwise uniform pattern, and hence 
> generally increases code complexity considerably. And all this just 
> because there are fuzzy locations...

Well, we all know fuzzies are evil!

> What I suggested is not really denormalization. You're right though, 
> there's duplication. If the coordinate types (which I mentioned 
> further down in the email in the part you cut) are just moved from 
> being location_qualifier_value associations to FKs on location, then 
> there isn't really duplication anymore either. Or am I missing 
> something?

It's still duplication for the cases where the actual maxima and minima
are in location_qualifier_value.  I guess you could go to whoe
way and get rid of location_qualifier_value completely and put max
and min slots on seqfeature_location.  But that leaves the table rather
bloated.

I still think this is really something to be solved in software
(and yes, it's a good example of why strict 1-to-1 tables-to-adaptors
doesn't really work once you have too much structure in your data).  If
you want to work around it in the database, why not just put a boolean
`here be qualifiers'  flag on seqfeature_location?  This has less impact
on the location table than 3 FKs to ontology_term, and I can't really
see it being any slower, since code that has discovered fuzzies is
likely to want to go to the location_qualifier_value table to get the
whole story anyway.


     Thomas.