Talk:GEPS 010: Relational Backend

From Gramps
Revision as of 17:25, 26 March 2009 by AaronS (talk | contribs) (moving discussion to the discussion page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Discussion

I suspect that we would have something like SQLite as a default, but allow experts to move to more sophisticated backends.

It is quite powerful, but perhaps more sophisticated than what we need. I think we want to find the right balance between power and dependencies.

What you looking for here is called a Database Abstraction Layer they are
indeed quite powerful and are exactly what you need. if your going to bother
switching the back end don't waste your time and not use one. you'll kick
yourself later if you don't. just be careful which one you choose. I know
that in php every web framework seems to have their own. I suspect the same
for python. Django has their own but allows for the use of others (if that
 tells you anything). might be a place to check for alternatives. While
 their framework might be for websites that shouldn't matter for the DB
 Abstraction layer.

What to look for in a db Abstraction Layer is which dbs it can use. sqlite and
 mysql are musts, you may even find one that can talk to BSDDB but probably not.
 Oracle and PostgreSQL
 are pluses but will probably never be used but who knows what will happen in 5
 or 10 yrs. who knows maybe oracle would get fed up with mysql and release the db
open source charging for service. stranger things have happened.
ease of use, readablity and outer joins are also important. don't worry too
much about how complex of sql queries its supposed to allow you to create since
complex queries through a db layer tend to be difficult to create, read and predict.
ie sub queries and the like. usually those queries are far easier to just build as a query.

in my experience a db abstraction layer is good for most of the db io. however, for
the complex stuff a sort of localization object (or even file) is a good bet with named
queries. this would work similar to how different languages are usually supported in
projects. with a different object or file per db. I'd recommend an actual object with a
function per query over a
file of constants/variables since some db's might require a little more manipulation than
others. again this would only be for the most complex queries. a good rule of thumb would
be if you had to start writing parts of the query as strings move it to the db localization
 object. This db localization object isn't used for all queries because you only want to have
to tweak the minimum amount of queries across dbs
--Aarons