Re: Re[4]: Database design goals...

[mike_phillips urscorp com]

>  A simple version of SQL might work OK, but I'm a little suspect
>that it might get messy for the case of the embedded "back
>ends". Keep in mind they don't have any sort of query language
>to translate to, so the language would need to be mapped to
>the home brewed methods of access. A simple SQL might be more
>attractive, but it might need to be "dumbed down" so much that
>there's little benefit?

This is the biggest issue with implementing a generic interface. 
Either a decoder is written for the databases without a query
language or we dumb down the functionality of the databases 
that do provide a complete query language. 

>Here's a more functional approach;

>ret = db_lookup(rec_type, rec_field, field_value);

>  rec_type = "APT", "NAV", "AWY", etc.

>  rec_field = "IDENT", "NAME", etc...

>  field_value = "KJFK", "JOHN F KENNEDY INTL"

This is really easy to implement in all database formats, the only 
downside is that you need multiple accesses to get all the information
you need, rather than one "select * from arpt where faa_host_id='nnn';"

>ret = db_nearby(ident, distance);
>  a function that returns a list of nearby airports and navaids

Again, very simple to implement in all database formats. 

An ultimate goal would be to enable a user to do something like this:

Show me the airports with at least a 3000ft runway, 100LL fuel within 
a 300 mile radius. 

This would actually lead into being able to calculate a flight plan
between airport a and airport b, calculating multiple stops based
on criteria set up by the user, i.e. direct, airways, via radio navs.

Mike