[AccessD] The direction of data processing

 Hi Jim and Gustav --

<<<
What a moment to bring a potent Oracle server on its knees. That must have
been a cup of coffee you never forget.
>>>
Oracle devs are known(?) to charge their Oracle servers with long running cycled SPs utilizing cursors - wasn't that the case?
As opposed to MS SQL T-SQL devs who mainly write set-oriented data manipulation SPs - so even when processing large data volumes they keep their MS SQL Servers flying... :)

As for NoSQL - Redis ( http://redis.io/ ) somehow keeps constantly popping-up in the IT-related stuff I'm reading - so Redis (and Hadoop) - are on first positions in my NoSQL bookmarks...

-- Shamil

Monday, January 27, 2014 9:13 AM +01:00 from "Gustav Brock" <gustav at cactus.dk>:
>Hi Jim
>
>For the last days I have been struggling with some updating pass-through
>queries, not Oracle but T-SQL.
>No fun. As soon as you have more than a few joins, the code turns nearly
>unreadable. I'm not very good at it, so I had to build the query and the
>joins bit by bit to not lose my feet. I never learn to love this. Give me C#
>please.
>
>What a moment to bring a potent Oracle server on its nees. That must have
>been a cup of coffee you never forget.
>
>/gustav
> 
>
>-----Oprindelig meddelelse-----
>Fra:  accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com] På vegne af Jim Lawrence
>Sendt: 27. januar 2014 06:03
>Til: Access Developers discussion and problem solving
>Emne: [AccessD] The direction of data processing
>
>Hi All:
>
>I must admit that there is a bit of a preamble to but it is all aimed at a
>point and, I believe, the future in data management.
>
>Back a number of years ago, when working for a government branch that
>handled data and policy I was asked to retrieve a full set of data summaries
>and have them ready to display and/or printout at the request of the
>department head. To say the least the data was a mess. It had evolved for
>years and each time the data model was improved the data structure was
>changed and because it was easier to just make a new table than try and
>figure out how to consolidate the information in one table. To add to data's
>complexity, government policy continued to change and affect how data
>entered into the existing table. When the variation became too extreme time
>for a new table.
>
><<< tail skipped >>>