[std.database]

Regan Heath regan at netmail.co.nz
Mon Oct 10 04:19:51 PDT 2011


On Sat, 08 Oct 2011 17:19:02 +0100, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 10/8/11 8:36 AM, Adam Burton wrote:
>>> I'd also like to get a feel for the magnitude of the task, so I'd like  
>>> to
>>> ask what database systems you think should be supported.
>> mysql, postgresql, sqllite are the 3 I am aiming at in my personal
>> implementation.
>
> I had lunch yesterday with a database expert and discussed the matter  
> with him. He advised that we take a driver-oriented approach in which we  
> define a common API for all databases (modeled at high level after e.g.  
> JDBC to reuse that accumulated experience)

Just a small note, because it's on my mind currently, with regards to  
JDBC.  This is slightly OT, but pertains to the comment about how we  
should model std.database.

JDBC has Statement and PreparedStatement objects, the latter allows you to  
'bind' parameters, which is great.  But, it requires you actually  
'prepare' them as well.. I am not 100% certain, but I believe similar  
C/C++ code can bind parameters without actually 'preparing' the statement  
for reuse.  We use this in cases where we do not re-use the statement, and  
want to avoid the excess work of preparing it for re-use.  In addition we  
bind parameters to avoid getting unique query strings, which (I believe)  
get cached by SQL server.. resulting in thousands of unique queries in the  
cache, slowing things down.

So, my comment is simply to say, assuming I am not talking rubbish, make  
sure the design allows for binding/not binding parameters with  
prepared/not-prepared statements.

This came up recently because some of our JDBC code was taking 12 minutes  
to do a select, due to using a PreparedStatement, and changing to a  
Statement reduced this to <10 sec.  But, it means the select is now  
unique, and we will be introducing more cached queries.. anyone know how  
to avoid this using Statement?

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/


More information about the Digitalmars-d mailing list