Talk:GEPS 010: Relational Backend

From Gramps
Revision as of 18:01, 26 March 2009 by AaronS (talk | contribs) (adding old discusion)
Jump to: navigation, search

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.

It's good to see this discussion on gramps and is actually why I'm thinking of giving
it another try depending on how hard it is to implement this. Yes I know it will be hard
but probably much easier and productive than starting my own project. I'm  a developer my
self and when it came time to evaluate gramps the lack of a relational db backend was one
of the main reasons I decided to keep looking.

Don't discount MySQL over SQLite. While I haven't tried it out yet there is an embeddable
 version of MySQL which might overcome some of sqlites advantages. If a database abstraction
 layer is used both could be
 easily supported. They both have their advantages and disadvantages.



Personally I think SQLite makes more sense for genealogical software. but mysqls
tools and the fact that it's a "real" enterprise level relational db are serious advantages.
-- AaronS


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