[DUG] The BDE API formerly known as the Paradox Engine

[Neven MacEwan]

Paul

What I meant was that ISAMs encouraged Key->Prev/Next, PgUp/PgDn data 
navigation, whereas
RDMS didn't work that well with this logic, better to use Key -> Subset 
-> Select from list logic, which
fits with larger datasets, though you will occasionally see a recidivist 
hammering the page down key as they
search for 1 item in 10,000 rather than type a few characters

Neven

> Neven wrote: 
>
>   
>> I sometimes wonder if the problem is that developers start 
>> with too small sets of test data and design their navigation  
>> logic around that not realising of course in real life above 
>> a 100 records or so the rules change
>>     
>
> Hrmm.. I don't think it's really a data size or data structure thing. We
> have clients with 30Gb+ Accredo databases and lotsa users and it perform
> well for them. Large data volumes need thought (and appropriate index
> use!) whether it's navigational or relationally accessed. 
>
> After all, relational is something you generally layer on top of a lower
> level navigational tuple store anyway - that's how most major relational
> engines work, starting from the original System-R from IBM.
>
> If you look at the history of the relational model, the advantage was
> declarative vs procedural query specification which which was driven by
> the need for easier ad-hoc reporting and accellerated by the fact that
> it gets tricky in large complex databases for _developers_ to figure out
> _how_ to choose (and successfully code!) a good access plan given the
> varying data distribution and available access options (indexes, join
> orders, etc.)
>
> That's what SQL execution engines _do_ at their core - query optimise
> (hard) and then execute (easy). Many cheaper ones do this quite poorly
> as query optimisation is hard to do well. As our developer, Steve knows
> - since he got to write a (pretty?) good one (well, much better than
> DBISAM) at my insistence :-)
>
>   
>> One thing I hated about ADO was its insistence on concurrency 
>> control, I design my dbs so concurrency is not required but 
>> it insisted on it, which was also a legacy of 'client side'
>> business logic (ie VB/Access apps), it was I must say a step 
>> up from the BDE 'Primary Key? what's a Primary Key?' approach
>>
>> Maybe we should start a list -- 10 no a 100 things i hated 
>> about the BDE
>>     
>
> Well, I'm sure the others on the list are starting to feel like they've
> had to wade through that already with me opining away. So I'll shut up
> now unless anyone actually asks more questions :-)
>
> TTFN,
>   Paul.
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject: unsubscribe
>
>
>