Changes

Jump to: navigation, search

GEPS 010: Relational Backend

202 bytes removed, 18:21, 26 March 2009
adding and refactoring questions and concerns
SQL stands for "Structured Query Language" and is pronounced "sequel" (it is a joke: as it came after QUEL, it is its sequel).
= Reasons for making the switch adding a sql backend =
Currently, GRAMPS uses a BSD database as its internal file format. While this is considerably better than, say, an XML format, the choice of the BSD-DB has a considerable number of drawbacks. This proposal explores the use of SQL as an alternative backend. This should allow easy, single db file implementations (eg, SQLite) to more complex and sophisticated client/server (eg, MySQL).
# SQL is a declarative, independent abstraction layer
# SQL can optimize queries (in low-level C) whereas BSDDB is done in Python
# SQLite tables of a database reside in a single file Next, are a number of claims that need to be tested: # An SQLite SQL version of a GRAMPS BSDDB may DB should be 4 times smallerfaster# An SQLite version of a GRAMPS BSDDB may be faster## The files may DB should be smallerthan a BSDDB file.## The smaller files may allow more into memorySQL Engines can perform query optimizations## More code would reside in Cthe db, rather than in Python## SQL Engines can perform query optimizations
# Enterprise SQL versions of GRAMPS would allow people to create and manage much larger trees
# An SQLite version of GRAMPS might allow people to create larger trees
Further implications:
# A fullscale MySQL backend would be a trivial step from SQLite (although maybe harder to setup and maintain; although see Django)
# Easy to allow multiple users in a SQLite database (uses file-locking)
# There is a lot of code that we have written dealing with BSDDB. It would have to all be rewritten in SQL (on the other hand, a lot of code can be deleted, which will make GRAMPS easier to maintain and adapt)
= Questions and concerns =
   == Additional Issues Native DB access for other languages == 
If we use a well-known SQL backend, we should consider the ability for other languages to be able to natively access the database. For example, a PHP program should be able to use the same database. Does using a Python-based ORM tie the data to Python? Or can the database still be used natively from other systems?
Using a Python based ORM wont tie the data just to python. any language should be able to access the db just fine. However, they wouldn't have access to pythons orm layer. Since I haven't used a true orm before I'm not certain exactly how it will effect our table relationships but I don't believe they wont make some sense in a relational way. Not that I'm saying we should use it but a quick google search started to bring up things like this [http://pecl.php.net/package/python php python package]. so there may be some hope for even using the orm layer but how complex would we really want to make it! And of course there is always the option of just using an orm and building similar objects in the new language. --[[User:AaronS|AaronS]] 03:30, 26 March 2009 (UTC)
    === Power vs Dependencies === 
Do we want to have an additional layer over the Database Abstraction Layer (eg, an ORM)?
76
edits

Navigation menu