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.
...mark (Mark Rabideau)
ManyRoads Family Genealogist (Rabideau-Henss Family); Professional Genealogist
Visit us at: http://many-roads.com
Snail mail at: 711 Nob Hill Trail - Franktown,CO USA - 80116-8717
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 <email@example.com> 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 (http://gramps-connect.org/) 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 . There are many other viable options that did not exist 6 years ago when the decision to switch to BSDDB was made.Doug, 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 . 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.John, 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 MongoDB). -DougRegards, John Ralls  http://www.oracle.com/technetwork/database/berkeleydb/overview/index-083851.html------------------------------------------------------------------------------ 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. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Gramps-devel mailing list Grampsfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/gramps-devel