[FAQ] API vs SQL for VSERVER access // Some comments

Ruslan Zasukhin sunshine at public.kherson.ua
Thu Aug 31 23:04:01 CDT 2006


On 8/31/06 9:24 PM, "Erik Mueller-Harder" <erikmh at gmail.com> wrote:

Hi Erik,

>> Important point.
>> 
>> * !!! While you develop SERVER product -- AVOID API way. You have read
>> article about ways in WIKI ?
>> 
>> You must use SQL way: SQ: commands, Joins, Cursors. Because this way support
>> record locks.
> 
> Yikes! Really? Here's all that I've found in the Wiki:
> 
>> The main disadvantage of the Pure API style compared with the SQL
>> Style of coding arises when working with a remote server.  Using the
>> SQL Style programs send small string-based commands to server and
>> the remote DBMS can do a lot of work to provide the requested
>> result. With the API Style developer must obtain and operate on
>> potentially large intermediate results in the client computer which
>> can result in the network becoming a significant bottleneck.
>> 
>> On the other hand, given a fast high-bandwidth network connection
>> the API Style still can be used quite effectively; especially since
>> fast modern networks can often be faster than accessing data from a
>> slower local hard disk drive.
> 
> I'd assumed from this that I could use the pure API style as long as I
> took care to minimize the volume of data transferred. It's true that
> the server won't cope with record locking if I use the API style?

Look, main problem is not even in record locks.
    sooner or later we will add Vtable.LockRecords( set )

Main problem why SQL wins API way for REMOTE access is
    time of call to server.

If your server is located in other country via inet, it can take e.g. 1-2
seconds for response. Never mind if you ask something simple as RecId,
Or for set of records (e.g. 5-10Kb).

You see?

API way require MANY calls to server.
SQL way send small SQL string and get back some result.

This was one of main reasons why SQL-based RDBMS have win war agaist
Hierarchical and Network dbs in 1980s.

If you ask - why you then support API way for VSERVER, answer is:

* we want that API of V4RB did work as LOCAL so REMOTE.
    it is other question how effective it will work,
    but it will.   

* we consider MAIN usage of API_way + VSERVER for LOCAL only network,
    and even better for FAST local networks as 1Gb

* May be somebody of developers will start developer LOCAL only project, but
many months later he will need some kind of multi-user access. IT should
just work in most cases.

BUT if you start new project, and you from start target REMOTE server, it is
good idea to use mainly SQL way...API commands also can be used in some
not-hot places...You should watch for this..

* we give you tools, we decide what and when to use to get best trade off.

-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]




More information about the Valentina mailing list