I suspect that we would have something like SQLite as tried to keep these in order and make a default, little more sense out of them but allow experts to move to more sophisticated backendsit's still a bit rough. --[[User:AaronS|AaronS]] 18:33, 26 March 2009 (UTC)
It is quite powerful=Databases=I suspect that we would have something like SQLite as a default, but perhaps allow experts to move to more sophisticated than what we need. I think we want to find the right balance between power and dependenciesbackends.-- ?
<pre>
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.
DonIt't discount MySQL over SQLite. While s good to see this discussion on gramps and is actually why I haven't tried m thinking of giving it another try depending on how hard it out yet there is an embeddable version of MySQL which might overcome some of sqlites advantagesto implement this. If a database abstraction layer is used both could Yes I know it will behard but probably much easier and productive than starting my own project. I'm easily supported. They both have their advantages a developer my self and disadvantageswhen 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
=Database Abstraction=
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. --?
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
</pre>
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.
<pre>What you looking to look for here is called in a Database db Abstraction Layer they areindeed quite powerful is which dbs it can use. sqlite and mysql are exactly what musts, you need. if your going may even find one that can talk to botherswitching the back end don't waste your time and BSDDB but probably not use one. you'll kickyourself later if you don't. just Oracle and PostgreSQL are pluses but will probably never be careful which one you choose. I knowthat used but who knows what will happen in php every web framework seems to have their own5 or 10 yrs. I suspect who knows maybe oracle would get fed up with mysql and release the samedb open source charging for pythonservice. Django has their own but allows for the stranger things have happened. ease of use , readablity and outer joins are also important. don't worry too much about how complex of others (if thatsql queries its supposed to allow you to create since tells you anything). might complex queries through a db layer tend to be a place difficult to check for alternativescreate, read and predict. While their framework might be for websites that shouldn't matter for ie sub queries and the DB Abstraction layerlike. usually those queries are far easier to just build as a query.
What to look for in my experience a db Abstraction Layer abstraction layer is which dbs it can usegood for most of the db io. sqlite and mysql are mustshowever, you may for the complex stuff a sort of localization object (or even find one that can talk file) is a good bet with named queries. this would work similar to BSDDB but probably not. Oracle and PostgreSQL how different languages are pluses but will probably never be used but who knows what will happen usually supported in 5 projects. with a different object or 10 yrsfile per db. who knows maybe oracle would get fed up I'd recommend an actual object with mysql and release the a function per query over a file of constants/variables since some dbopen source charging 's might require a little more manipulation than others. again this would only be for service. stranger things have happenedthe most complex queries.a good rule of thumb wouldease be if you had to start writing parts of use, readablity and outer joins are also importantthe query as strings move it to the db localization object. donThis db localization object isn't worry toomuch about how complex of sql used for all queries its supposed to allow because you only want to create sincecomplex queries through a db layer tend to be difficult have to create, read and predict.ie sub queries and tweak the like. usually those minimum amount of queries are far easier to just build as a query.across dbs --Aarons
in my experience a db abstraction layer is good for most of the db io. however, forthe complex stuff a sort of localization object (or even file) is a good bet with namedqueries. this would work similar to how different languages are usually supported inprojects. with a different object or file per db. I'd recommend an actual object with afunction per query over afile of constants/variables since some db's might require a little more manipulation thanothers. again this would only be for the most complex queries. a good rule of thumb wouldbe 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 haveto tweak the minimum amount of queries across dbs--Aarons</pre>=== Recomendations ===
Let me preface this by restating that I've never actually used any of these abstraction layers and I'm not yet familiar with the gramps code and developers strengths. Other people with more knowledge should be the ones making the decision. Also any decisions need to be revistable after we actually start coding in case they just don't work.
