En/na [EMAIL PROTECTED] ha escrit:
Martijn Faassen wrote:
Missing powerful query concepts
-------------------------------
Certain powerful query concepts like joins, available in a relational
setting, are missing. I've already run into a scenario where I wanted to
someting like this: given a bunch of version objects with field 'id',
where multiple objects can have the same 'id' to indicate they're
versions of the same object, I want all objects where field
'workflow_state' is 'PUBLISHED' unless there is another object with the
same id that have workflow_state 'NEW', in which case I want that one'.
I think joins would be a way to solve it, though I haven't figured out
the details, nor how to implement them efficiently on top of the
catalog. This kind of thing is where a relational database makes life a
lot simpler.
I used to have the same complaints in Zope 2, but so far I've been happy
with Dieter's AdvancedQuery product. See
http://www.dieter.handshake.de/pyprojects/zope/AdvancedQuery.html
It might be worth a look while thinking about what to implement for zope 3.
A very interesing discussion. I'm just and advanced Zope 2 user, and a
Zope 3 beginner, but those questions are over my head since I start to
develop using ZODB, so I will put here my opinions.
The use of ZODB and ZCatalogs has a lot of advantatges, that's obvious,
but also has some limitations. We also use AdvancedQuery to solve some
of them, but there are another not solved ones:
1) Join's. There isn't an standard way to make joins, and also to
make sorts and filters over joined data. I know that with enought
python knowledge this can be done manually, but that's hard (at least
much more hard than using SQL). Moreover, programmers writing business
application reports are the ones with less python experience and,
believe me, some joins can be writted in a very unefficient way :-)
2) Relational Integrity. I like to make a data definition and rely on
it, so if I define that an invoice has a restricted foreign key with a
customer, the customer will not be deleted while the invoice exists.
Despide this behaviours could (and should) be implemented in the
application logic, sometimes there are bugs in the application and data
inconsistencies are generated. Working with RDBM's you could rely on
your data definition, so data inconsistencies never will be done.
3) Huge amounts of data. When working with applications writing a lot
of data or making queries (in special join's) over huge amount of data,
the performance of a ZODB database is poor in front of some RDBM's (I'm
talking about Zope 2.7, I haven't this experience with Z3 yet).
Despide of this, I think the advantatges of use ZODB are more than the
limitations, so we continue using it. I think a good approach could be
a transparent O/R mapping plus a way to use SQL over the RDBM's and get
objects back. That way, a pure ZODB application can work with
FileStorage or with a RDBM's storage, and applications requiring it will
be able to take advantage of SQL.
I just want to express an opinion from a user that simply uses ZODB and
ZCatalogs, and that has been using RDBM's for a long time before.
Regards
Santi Camps
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
