[geeks] SQL Performance

[Shannon Hendrix]

On Jul 22, 2008, at 11:50 , Jonathan C. Patschke wrote:

> On Tue, 22 Jul 2008, James Fogg wrote:
>
>>>> If you need direct access to a RDBMS via the network on an embedded
>>>> platform, you have Other Problems.
>>>
>>> Why?
>>>
>>> I've worked on a couple and have seen a lot use remote services of
>>> various kinds, databases included.
>>
>> Same here, I work with an application that is a huge DB client (50G
>> database, up to 150 TPS).
>
> Network access to an RDBMS is inherently about as far from a real-time
> facility as you can get.  If you're designing something that  
> requires a
> real-time OS, building in such a requirement can very quickly make  
> things
> a gigantic mess.  Also, my limited understanding of the DB2 and Oracle
> protocols reveals them to not be neither very lean nor predictably
> bounded, in terms of processing or memory requirements.

A good realtime OS can handle both realtime and normal processes.

There are obviously some primitive realtime OS and really small  
systems you wouldn't do this with, but it's really not that big a  
problem.

I wrote one years ago that was hard realtime, and every few minutes it  
would upload data to an SQL server.

Never had an issue.

> If you're designing a hard real-time system (ie: you actually -need-  
> an
> operating system like QNX or VxWorks, and aren't just trying to show  
> off
> how obtuse you can be), that lack of predictability might, quite
> literally, be destructive.

If you were to try and put the database operations in the realtime  
tasks, sure.

But then... that's a really dumb thing to do.  In fact, it's better to  
avoid that even on a standard non-realtime UNIX system if you can  
manage it.



-- 
"Where some they sell their dreams for small desires."