David.Poole (2/3/2014)
From a developer perspective ... The problem is that the choice isn't always that well informed or even informed.
But I have seen some of the uninformed development types. And that was with a set of Access DBs for ETL (stove piped systems). After the uninformed dev type was no longer with the company we rebuilt all his stuff from the ground up and regained about 25-30 hours of processing time from/for the level I staff.
One of the selling points of a distributed system is that fault tolerance is built in by holding multiple copies of everything. Because of this extra level of redundancy, the argument goes, you can run this little lot on commodity kit.
The problem with going to the commodity kit model is the typical management staff doesn't understand that buying a bunch of Dell Tungsten level servers with a RAID setup is still never going to have the same performance of a full up server designed with the production model in mind.
So there is a combo of problems. And I have run into it before. I have had delivered apps that I delved into the SQL code and it was horrible on the SQL side. I had no clue of the exe/dll content, but the SQL didn't reassure me. The DB normalization was very questionable. It looked mostly like a 4th level norm then bast***tized to a 2nd level.
The devs who are writing very questionable code meet up with the the user/buyer company management that will only buy crap commodity equipment and your app runs like crap.
The buyer company IT team is screwed by management and the dev company because the end-user says "I should use a typewriter and a form." And what's sad is they are right.
So I look at the NoSQL as a waste until the devs can do efficient code and the management is willing to invest in infrastructure.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.