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 =
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
# 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
# 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)
Additional Issues ==
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)
Do we want to have an additional layer over the Database Abstraction Layer (eg, an ORM)?