Not that anyone asked but... and probably everyone already knows this stuff much better than me...
Pax vobiscum,

Pax vobiscum,

On 11/26/2011 04:28 PM, Mark F Rabideau wrote:
I know that my sense in this regard is not to be trusted, AT ALL!... but personally I would do anything possible to avoid an Oracle product.

Pax Vobiscum,
...mark (Mark Rabideau)

ManyRoads Family Genealogist (Rabideau-Henss Family);  Professional Genealogist
Visit us at: 
Snail mail at: 711 Nob Hill Trail - Franktown,CO USA - 80116-8717
phone:+1.303.660.9400  fax:+1.303.660.9217
member: Association of Professional Genealogists & National Genealogical Society
"It’s always useful to know where a friend-and-relation is, whether you want him or whether you don’t."

Rabbit, Pooh’s Little Instruction Book (Winnie the Pooh)

On 11/26/2011 12:17 PM, Doug Blank wrote:
On Sat, Nov 26, 2011 at 1:32 PM, John Ralls <> wrote:
On Nov 26, 2011, at 8:45 AM, Doug Blank wrote:

For example, we have a web-based, server version of Gramps under
development ( that promises to be a good
solution for large databases, and collaborations. We just recently
learned that the current Gramps Gtk-based structure can't be beat in
terms of efficiency of access. We now replicate that structure in SQL
on the webserver, so that one can run all of the same code. One option
that this suggests (at least to me) is that we could keep the current
hierarchical Gramps data structures, but use something like sqlite (or
a No-SQL product) as the backend. Sqlite has a good record of
remaining backwards compatible [1]. There are many other viable
options that did not exist 6 years ago when the decision to switch to
BSDDB was made.

If you're really thinking about changing the backend architecture, I suggest that you have a look at XQuery-based XML solutions like Oracle's DBXML [1]. Although most commercial Genealogy applications do use some sort of relational database for a backend, the fixed-format table structure is less than ideal for genealogical data. Semi-structured solutions are more appropriate, and XQuery provides a ready-made and very rich query framework for accessing the data.

I would like to see us move to a better backend at some point.
However, I don't know about DBXML. This looks to be a bit more useful
than what we currently have, but wouldn't necessarily fix any of the
following major issues:

1) file format keeps changing

2) trouble keeping the underlying software built for Mac, Linux, and
Windows (need low-level C code, and Python wrappers)

3) lack of experts on our team at the DB layer

Rather, I'd be more in favor of moving to a well-established, stable,
long-term viable file format. Or making a layer that allows us to be
agnostic as to what the low-level is (eg, Django).

I do like the idea of being able to write queries in DBXML (eg, the
schema is part of the dabase, where it belongs). But many of the new,
open source NoSQL databases allow that as well (eg, CouchDb and


John Ralls


All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
Gramps-devel mailing list