| Subject | Re: [IB-Architect] Odbc/Jdbc Driver |
|---|---|
| Author | Jim Starkey |
| Post date | 2000-05-19T15:59:02Z |
At 11:43 AM 5/19/00 -0400, dcalford wrote:
SQL belongs in the engine. When we started, it wasn't obvious that
SQL would win. It shouldn't have, but it did. That being that, the
long term answer is to push SQL deeper into the engine consistent with
backwards compatibility.
The place where the question becomes important is compiled statement
caching. Short of fixing the optimizer, this is probably the best
cheap performance tweak. Should it be done at BLR level or SQL
level? BLR is more general, but requires that each DSQL statement
be parsed, resolved, analysised, and transmogrified into BLR, all
of which is expensive.
The design center for InterBase was an assumption that the bulk of
database requests would result with either precompiled programs or
high level query systems. For each, BLR was a very good answer.
BLR is easier to generate, more powerful, more explicit, and vastly
easier to rip apart for execution the SQL. But, alas, SQL won.
Worse, SQL is such a bogus standard that SQL often gets ripped apart
at various transmission layers to coalesce dialects, get parameters,
etc. So for contemporary architectures and usages, there is no point
is worrying much about BLR at all.
Anyway, the final answer of where InterBase development is going
is not from Ann nor me nor Charlie but the folks in the InterBase
community who sieze the opportunity and run with it.
Jim Starkey
>Hi Jim,I don't speak for InterBase. That's Ann's department. Philosphically,
>
>Jim Starkey wrote:
>
>>
>> [Note: a client side DSQL whomps server side any day.]
>
>Do you prefer Client side programing over server side?
>Are you advocating that we should do as much as we can on the client?
>Should we try to make the server side DSQL as fast or faster than client
>side?
>I prefer extremely thin clients. It makes support, updates, in fact,
>overall maintenance simple.
>It also keeps development costs down.
>One of the reasons I use interbase is that is allows me to do this without
>using a third party
>middle ware product.
>I need to know where you see Interbases development heading.
>
SQL belongs in the engine. When we started, it wasn't obvious that
SQL would win. It shouldn't have, but it did. That being that, the
long term answer is to push SQL deeper into the engine consistent with
backwards compatibility.
The place where the question becomes important is compiled statement
caching. Short of fixing the optimizer, this is probably the best
cheap performance tweak. Should it be done at BLR level or SQL
level? BLR is more general, but requires that each DSQL statement
be parsed, resolved, analysised, and transmogrified into BLR, all
of which is expensive.
The design center for InterBase was an assumption that the bulk of
database requests would result with either precompiled programs or
high level query systems. For each, BLR was a very good answer.
BLR is easier to generate, more powerful, more explicit, and vastly
easier to rip apart for execution the SQL. But, alas, SQL won.
Worse, SQL is such a bogus standard that SQL often gets ripped apart
at various transmission layers to coalesce dialects, get parameters,
etc. So for contemporary architectures and usages, there is no point
is worrying much about BLR at all.
Anyway, the final answer of where InterBase development is going
is not from Ann nor me nor Charlie but the folks in the InterBase
community who sieze the opportunity and run with it.
Jim Starkey