[AccessD] The direction of data processing

Hi Shamil

Yes, and Hadoop even runs at Azure:

http://www.windowsazure.com/en-us/documentation/services/hdinsight

/gustav

-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] På vegne af Salakhetdinov Shamil
Sendt: 27. januar 2014 09:38
Til: Access Developers discussion and problem solving
Emne: Re: [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 >>>
--