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

[mike_phillips urscorp com]

John,

I don't have any problems with the comments you've put forward. For a 
standalone application that's simple to install and use, having a built-in 
(either existing or statically linked db1) makes perfect sense. For people 
who want to use fplan in full-on mode, its up to them if they want to 
install and use a backend database server. Most distributions will install 
either MySQL or Postgres as default anyway, and a quick apt-get install 
postgres doesn't take that long :)

Once we've been through a couple of iterations and got down exactly what 
information we want out of NASD/DAFIF its no trouble to update avdbtools 
to produce the format we want. (What would be really nice of course would 
be to have the DAFIF update as part of fplan itself. Running avdbtools is 
not that hard, but if we're talking about making things as easy as 
possible for users....) 

I'm on vacation next week, but I'll start work on the generic interface 
next and getting it to work with the existing files and functions. The 
question here is whether we produce something that just emulates the 
existing data queries (which means each new function added would require 
an addition to the interface code), or whether we write a generic-generic 
interface code, i.e. something that will interpret a query string and 
return the values. This would make future development a lot easier, and 
actually make the interface api simpler, but make the interface itself 
more complex as it would have to interpret the query and translate it into 
the format for the required data file. 

The use of index files is definately beneficial but should be transparent 
to the developer/user, the db interface should take care of all this. 

I would like to get to the point that a developer can simple use something 
like the following:

struct db_values_t { 
        fname char[16] ; 
        fvalue char[256] ; 
} ; 

struct db_values_t *ret ; 

ret = db_query("get airport_details 17N") ; 

So ret would be a pointer to a list of tuples with the information from 
the database. 

Once the syntax of the query is decided upon (a simple version of sql may 
do the trick), it would be easy for a developer to add new functionality 
to fplan and not worry about the database side. e.g. to get a boundary 
list of navaids:

ret = db_query("get navaids range N39,W80 - N35,W75") ; 

The other, simpler way is to create individual functions for each type of 
query, i.e.

ret = db_query_aprt("17N") ; 
 
ret = db_query_navaids("range N39,W80 - N35,W75") ; 

Anyway, a lot of the details will come out in the wash once we start 
putting this together.

Mike