durusmail: durus-users: OODB vs SQL
OODB basics
2005-10-08
2005-10-09
2005-10-09
2005-10-09
2005-10-09
2005-10-09
2005-10-09
2005-10-09
2005-10-09
2005-10-09
2005-10-11
2005-10-12
Re: OODB basics
2005-10-11
OODB vs SQL
2005-10-09
2005-10-09
2005-10-09
Re: OODB vs SQL
2005-10-10
Re: OODB vs SQL
2005-10-10
OT: Durus
2005-10-13
2005-10-13
2005-10-13
2005-10-09
2005-10-09
2005-10-09
2005-10-10
2005-10-11
2005-10-11
2005-10-11
2005-10-11
Re: OODB vs SQL
2005-10-11
2005-10-11
2005-10-11
2005-10-12
2005-10-12
2005-10-12
Demo application [was: Re: [Durus-users] Re: OODB vs SQL]
2005-10-13
Re: OODB vs SQL
2005-10-11
Durus basics
2005-10-09
2005-10-09
2005-10-10
2005-10-10
2005-10-10
2005-10-13
2005-10-13
2005-10-13
2005-10-13
Re: OODB basics
2005-10-13
OODB vs SQL
mario ruggier
2005-10-11
On Oct 10, 2005, at 3:12 PM, Rodrigo Dias Arruda Senra wrote:

> On Sun, 9 Oct 2005 14:36:03 -0400
> David Binger  wrote:
>
>> C.J. Date's "Database In Depth" gives an interesting description of
>> the relational model and how SQL falls short of the ideal.
>> Although he mocks OODBs, I still liked his book.
>>
>>> OODB advantage: there is no impedance mismatch between the OODB and
>>> the  programming language - the OODB stores language objects.
>
> I wonder if C.J.Date mentioned anything about databases for storing
> large dense graphs in that book ? I suspect this is an area where OODB
> would be more suitable than Relational DBs.

One thing I would like to understand better is what characteristics of
a problem make for an OODB would perform (human + performance) better
than a relational implementation. An aspect of this comparison I have
always wondered about, but never measured, is that  correlation of data
must be done:
(a) either directly with SQL (!)
(b) or using directly the basic resultsets in python obtained from an
SQL query
(c) or initialising rich domain-savvy objects, using an ORB or an OODB
directly

Which one of these approaches is:
- easier to design, implement, maintain, evolve?
- gives better performance?

Frankly, options (a) and (b) are not interesting, unless they are very
well paid ;)
Option (c) begs another question... in addition to the potential
impedance mismatch problems introduced by the OR mapping layer, what
gives better performance:
- SQL query -> creation of rich objects ?
- "Reviving" persisted rich objects ?

> Just to give an example, the Brazilian Government is sponsoring a
> project
> to build an AI system to double-check tax declarations. We are talking
> about
> 200 million people. One of this project goals is to examine the
> relationship
> graph (family, employment, etc) trying to detect fraud. Even though
> that can be
> modelled in a Relational DB, I'll investigate if an OODB with an
> appropriate
> storage would give better performance. My instinct says yes.

I would also be very intrigued by the design choices of such a storage.

> By the way, I helped another federal project to build a Python desktop
> app to
> record info from more than 150.000 public schools. While working
> off-line,
> such app used Twisted + **Durus**. But unfortunately, due to the
> rampant corruption
> unveiled recently, the project is in the freezer. If it ever gets out
> I'll let
> you know.

Wow... is there any chance that you could say more about this
experience? How did Durus hold up? How did you use it? Little things
that help, things to avoid?

mario

reply