[Zope-DB] Relational Databases in Zope 2 and Zope 3

[Tres Seaver]

Charlie Clark wrote:
> On 2004-06-29 at 17:17:13 [+0200], Scot Roberts <scot.roberts at five.tv> 
> wrote:
> 
>>Tres Seaver wrote:
>>
>>
>>>The dilemma here is similar to the classic one between OLAP and OLTP:
>>>arbitrarily flexible queries are death to transactional throughput.
>>>
>>>If your application *needs* this flexibility, then you *can't* take
>>>advantage of prepared queries anyway, as there is no "canonical" version
>>>of the query to prepare.  There are is *huge* space of applications,
>>>however, which *could* benefit from prepared queries;  for them the
>>>price of DTML's flexibility is both painful and unneccessary.
> 
> 
> Yes, thank you Tres and Matt for very succinct statements of why Zope could 
> do better at RDBMS. I have an application that has say 2 or 3 query fields 
> and over a 100 ZSQL methods. Now, the discussion about whether this is the 
> right way to do things aside, I am sure that my development and my 
> application would benefit from some changes in ZSQL methods and Zope's 
> interaction with RDBMS.
> 
> 
>>>Tres.
>>
>>Which means that there's a need for both ZSQL Methods as they stand now
>>(perhaps with the dtml- bit removed from the tags) for those of us who
>>value flexibility over raw throughput and some other method for writing
>>prepared queries. Although have to wonder why I wouldn't just used a
>>stored procedure on the db server instead of having a prepared query in
>>Zope, because if I was that concerned with performance that's what I do.
> 
> 
> This goes back to my original point: ZSQL Methods have been good *enough* 
> so far for so nobody's got round to changing them. But there do seem to be 
> some people who think that there is benefit to be gained from supporting 
> positional parameters and doing templating differently than with 
> <dtml-sql>. We will produce something new and have to offer backwards 
> compatibility at a later stage - I'd like to disable it initially to be 
> able to focus on what I'd like to.

We are probably better off creating an entirely new thing, say 
'PreparedSQLMethod', which *doesn't* and *never will* support DTML; 
that way we can avoid trying to satisfy mutually incompatible 
requirements within a single piece of software.  Applications which 
would benefit from the performance win can migrate to use the new thing; 
  applications which don't care, or need the flexibility of the DTML-based
approach, can continue to use the old one.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com