[ZODB-Dev] What is meant by 'using RDMBS as the back-end storage'?

[Spicklemire, Jerry]

Jeff asked:

>> are some users' Zopes configured to flatten the object store directly
>> into an RDBMS as the primary storage, instead of zope's customary
>> 'database file'. Could you not query this with SQL from within Zope to
>> do ad-hoc reporting?

to which Monty replied:

> However, there is no 'flattening out' going on. It stores
> pickles in the RDBMS, so while you could query the database for ad-hoc
> reporting, the reports would not be readable. :) (Unless you were
> looking for reports on the last time Zope committed an object.) That
> said, the pickle spec is open, so there is nothing stopping you from
> reading pickles with external tools. Just unlikely that you'll find it
> too useful.

On the other hand, if you could drop native objects into an 
environment tuned to their "frequency", it would be handy to 
be able to run reports, but beyond that, to perform any number 
of other as yet unimagined manipulations. This is where the 
Object-Relational goodies buried in PostgreSQL start to entice. 
Consider the classic example of the native spatial data types 
that have been in PostgreSQL from its inception as an 
exploratory platform for Object-Relational concepts.

A point data type, in 3D space, is defined as having three 
coordinates, x,y,& z. A line type is defined as having to 
terminals, each being a point. An arc has two terminals, 
labeled "start"and "end", a center (yet another point), 
and a direction. A radius can be derived, along with any 
number of other geometric relationships (chord, circumference, 
etc.) consisting of points, lines, arcs. None of these are 
complex enough to compel a departure from the relational model, 
each being defined as having a fixed set of properties, 
which map readily to rows and columns. 

Now, consider a polygon, with a random number of properties, 
made up of lines and arcs. Even this construct can be mapped 
to a parent-child relationship, so the need for an 
Object-Relational model doesn't stand out dramatically. 
Yet even this simple example demonstrates that an arbitrary 
number and type of properties and relationaships may be modeled 
so that native objects could be represented as new data types. 
Even code could be represented; e.g. branch type, loop type.

So, the question is, "why" does ZODB have to store pickled 
objects? Persistence doesn't require serialization, only 
storage and retrieval. The possibility of storing objects as 
native data suggests, at the very least, a radical way to 
apply patterns and perform re-factoring, and holds out the 
prospect of entirely new approaches to system design and 
analysis. 

my $.02,
Jerry S.