Programmers that code like that and actually get hired and supported by management that are one reason I'm giving up my career in IT. If the industry really wants results no better than what a trained chimp could do, they can have them. I'm going to go do something that at least is honest about the results being judge purely on personal preference and whim.
This case is NOT nuanced. Only the lawyers for the company that stands to make a buck want folks to think that. Did the printing company that, in olden days, typeset, print, and bind the laws in paper copies expect to profit from an exclusive license? No, they expected to get paid to do the printing and hand over the copies to the government. Possibly they could print up additional copies and sell them but they didn't expect to have any rights to the content.
It's distributed atomic transactions that don't scale.
As for the list of things you claim that NoSQL doesn't have, they are either so far outside of what a storage management system needs to do like On-disk encryption or clearly already part of some existing implementations, like automated failover between servers, clusters, facilities, datacenters, that I wonder if maybe Oracle hands out a talking points list of things to say about NoSQL technologies.
It's a good thing you have all those tools to analyze the queries and tables, because you need them to make that complex pile of enterprisey spaghetti work. If only there was something out there that just worked, and didn't need all that hand-optimizing and tool-fiddling to kludge it into usability.
More importantly, it would be great to have some kind of data storage system that developers could just use and not be forced to go through the bottleneck of the custodian of tools who, often as not, will use the "guide them to better data retrieval" excuse to refuse reasonable requests for straightforward functionality as violating some kind of holy normalization or relational purity dogma.
Blah blah blah constraints and hedges. Every time someone explains why a relational database doesn't work, one of the dogmatic faithful tries to dismiss it as a specialized corner case, but then goes on to assert that for "most datasets" and the "vast majority of databases" aren't under the same constraints. The problem is, there's no such thing as a "vast majority of databases". Everything has constraints, and RDBMS doesn't adequately address the vast major of them. Most systems that exist in the real world, as opposed to the idealized perfect Nth-normal form theoretical world, would have to be altered in ways that compromise the intent of the system in order to fit within the limitations of RDBMS system. Just as you noted how DNS couldn't be made to fit into RDBMS, but tried to pass off as a unique situation, no system needs the "flexibility" of an RDBMS. The relational model is one of those things that tries to solve all problems in theory and as a result solves none of them in practice. Yet the True Believers keep insisting that the most common practice is one that fits the relation model, when in fact the usefulness of an RDBMS is what limited to a few specially constructed case that have been molded to fit the ideals of the Date & Codd crowd.
Hey Bryce Jacobs, people know you are completely clueless. You've never known what you are talking about, and trying to hide your ignorance in wordy jargon-filled rants filled with weasel words isn't fooling anyone any more. Go back to playing with your little toy dBASE programs and leave the heavy lifting to people who understand how to implement post 1980s solutions.
Wrong. Every dogmatic RDBMS lapdog drags out the old "navigational database" claims, but that's just bs to cover up the fact that relational is a solution seeking a problem. Question for you: if relation is so great, why isn't the DNS system that is the backbone of the internet built on top of a relational schema? It's because the decentralized scalability we need for real-world applications can never be properly addressed by any relational implementation.
They may have been "designed" to scale, but they were clearly never tested or even trialed under real-world conditions. Distributed replication and transactions are a complete joke for scalability. As for "Many of those problems were solved in an "enterprise" DBMS 3-10 years ago", which ones specifically? Oh, right, none of them, because "enterprise" is just marketspeak for "really expensive and complicated but we promise it'll work great if you just sign over more money".
If I had a nickel for every organization handicapped by politically powerful but technically backwards database management people insisting that every development project be constrained to fit their idea of the "right" way to do data storage, I'd be retired and living on St. Croix.
Thank St. Codd we are finally getting away from the relational database dogma. I've seen more companies and projects crippled or completely killed by DB architects trying to enforce the One True Schema than just about any other idiocy in IT.
No sympathy from me. If the spokesdroid was being honest, he'd say "You take all the money you get from the government to put all you can in the ground, spend that money on executive bonuses and lobbyists, and then implement bandwidth restrictions to cover up your incompetence and greed. Oh yeah, you also use that as an excuse to kick your competitors off your incumbent network."
You'd think after so many decades of business programming this would become common knowledge. But I can personally attest to a system written (using Java) in the early 2000s that initially used float for money. When I was brought on to the project I pointed this flaw out. Neither the technical lead nor the programmer who had a math degree could be convinced it was a problem. The other programmers, chair-warmers with a COBOL background on their first Java project, ought to have known but they'd just leaned on Money to watch their backs.
Naturally the rounding errors eventually showed up on undeniable errors and I attribute the eventual abandonment of the project in part to the loss of time caused by having to backtrack and fix all the floats to use Java's BigDecimal.
Yes and no. EvE is really just a prettified version of Trade Wars. The fanbase is more interested in their spreadsheets and min/max calculations than any sort of embodied avatar.
The way banks and other financial services companies operate these days, working in gambling would be a GREAT introduction to the world of credit default swaps and mortgage-backed securities. Next stop: WALL STREET!
Sexism is an attitude, it doesn't have to be directed at specific individuals. If DHH says "Speaking of presentations. I'd much rather we banished kung-fu kittens and went with beautiful women for the filler stock art. Works in ads!" that's sexism, even though he's not directing a denigrating comment to a specific woman.
Also: some people in FOSS actually leave the parents' basement and meet face-to-face. Shocking, I know.
Yeah, but EVE Online is a graphically glitzy (something that requires horsepower on the client but not the server) but ultimately tediously boring rehash of Trade Wars. The server is mostly just a massive OLTP machine.
Slashdot Mirror
Programmers that code like that and actually get hired and supported by management that are one reason I'm giving up my career in IT. If the industry really wants results no better than what a trained chimp could do, they can have them. I'm going to go do something that at least is honest about the results being judge purely on personal preference and whim.
This case is NOT nuanced. Only the lawyers for the company that stands to make a buck want folks to think that. Did the printing company that, in olden days, typeset, print, and bind the laws in paper copies expect to profit from an exclusive license? No, they expected to get paid to do the printing and hand over the copies to the government. Possibly they could print up additional copies and sell them but they didn't expect to have any rights to the content.
It's distributed atomic transactions that don't scale.
As for the list of things you claim that NoSQL doesn't have, they are either so far outside of what a storage management system needs to do like On-disk encryption or clearly already part of some existing implementations, like automated failover between servers, clusters, facilities, datacenters, that I wonder if maybe Oracle hands out a talking points list of things to say about NoSQL technologies.
It's a good thing you have all those tools to analyze the queries and tables, because you need them to make that complex pile of enterprisey spaghetti work. If only there was something out there that just worked, and didn't need all that hand-optimizing and tool-fiddling to kludge it into usability.
More importantly, it would be great to have some kind of data storage system that developers could just use and not be forced to go through the bottleneck of the custodian of tools who, often as not, will use the "guide them to better data retrieval" excuse to refuse reasonable requests for straightforward functionality as violating some kind of holy normalization or relational purity dogma.
Relational databases already have excellent performance and scale extremely well
That must be why Google, Amazon, eBay, and Orbitz make them the foundation of their systems. Oh, wait, they don't.
Perhaps your definition of "excellent performance" that scales "extremely well" is one I'm not familiar with, however.
Blah blah blah constraints and hedges. Every time someone explains why a relational database doesn't work, one of the dogmatic faithful tries to dismiss it as a specialized corner case, but then goes on to assert that for "most datasets" and the "vast majority of databases" aren't under the same constraints. The problem is, there's no such thing as a "vast majority of databases". Everything has constraints, and RDBMS doesn't adequately address the vast major of them. Most systems that exist in the real world, as opposed to the idealized perfect Nth-normal form theoretical world, would have to be altered in ways that compromise the intent of the system in order to fit within the limitations of RDBMS system. Just as you noted how DNS couldn't be made to fit into RDBMS, but tried to pass off as a unique situation, no system needs the "flexibility" of an RDBMS. The relational model is one of those things that tries to solve all problems in theory and as a result solves none of them in practice. Yet the True Believers keep insisting that the most common practice is one that fits the relation model, when in fact the usefulness of an RDBMS is what limited to a few specially constructed case that have been molded to fit the ideals of the Date & Codd crowd.
Hey Bryce Jacobs, people know you are completely clueless. You've never known what you are talking about, and trying to hide your ignorance in wordy jargon-filled rants filled with weasel words isn't fooling anyone any more. Go back to playing with your little toy dBASE programs and leave the heavy lifting to people who understand how to implement post 1980s solutions.
Object databases could be a nice idea, but not for performance or scaling reasons.
[citation needed]
You're just talking out of your ass.
Wrong. Every dogmatic RDBMS lapdog drags out the old "navigational database" claims, but that's just bs to cover up the fact that relational is a solution seeking a problem. Question for you: if relation is so great, why isn't the DNS system that is the backbone of the internet built on top of a relational schema? It's because the decentralized scalability we need for real-world applications can never be properly addressed by any relational implementation.
They may have been "designed" to scale, but they were clearly never tested or even trialed under real-world conditions. Distributed replication and transactions are a complete joke for scalability. As for "Many of those problems were solved in an "enterprise" DBMS 3-10 years ago", which ones specifically? Oh, right, none of them, because "enterprise" is just marketspeak for "really expensive and complicated but we promise it'll work great if you just sign over more money".
If I had a nickel for every organization handicapped by politically powerful but technically backwards database management people insisting that every development project be constrained to fit their idea of the "right" way to do data storage, I'd be retired and living on St. Croix.
Thank St. Codd we are finally getting away from the relational database dogma. I've seen more companies and projects crippled or completely killed by DB architects trying to enforce the One True Schema than just about any other idiocy in IT.
No sympathy from me. If the spokesdroid was being honest, he'd say "You take all the money you get from the government to put all you can in the ground, spend that money on executive bonuses and lobbyists, and then implement bandwidth restrictions to cover up your incompetence and greed. Oh yeah, you also use that as an excuse to kick your competitors off your incumbent network."
Allison Randal, President emeritus of the Perl Foundation, Chairman of the Parrot Foundation, O'Reilly author.
You'd think after so many decades of business programming this would become common knowledge. But I can personally attest to a system written (using Java) in the early 2000s that initially used float for money. When I was brought on to the project I pointed this flaw out. Neither the technical lead nor the programmer who had a math degree could be convinced it was a problem. The other programmers, chair-warmers with a COBOL background on their first Java project, ought to have known but they'd just leaned on Money to watch their backs.
Naturally the rounding errors eventually showed up on undeniable errors and I attribute the eventual abandonment of the project in part to the loss of time caused by having to backtrack and fix all the floats to use Java's BigDecimal.
A 1964 publication by Paul Zindel entitled "The Effect of Gamma Rays on Man-in-the-Moon Marigolds" predates this research by quite a bit.
Yes and no. EvE is really just a prettified version of Trade Wars. The fanbase is more interested in their spreadsheets and min/max calculations than any sort of embodied avatar.
+1 Informative, accurate, and funny because it's true.
The way banks and other financial services companies operate these days, working in gambling would be a GREAT introduction to the world of credit default swaps and mortgage-backed securities. Next stop: WALL STREET!
Denial.
Sexism is an attitude, it doesn't have to be directed at specific individuals. If DHH says "Speaking of presentations. I'd much rather we banished kung-fu kittens and went with beautiful women for the filler stock art. Works in ads!" that's sexism, even though he's not directing a denigrating comment to a specific woman.
Also: some people in FOSS actually leave the parents' basement and meet face-to-face. Shocking, I know.
Sounds like you are full of Ire and Denial to me.
That's exactly the dismissive attitude that allows the problem to continue. Ire and denial.
People have already forgotten Matt Aimonetti's talk "CouchDB + Ruby: Perform Like a Pr0n Star." at the Golden Gate Ruby Conference?
Yeah, but EVE Online is a graphically glitzy (something that requires horsepower on the client but not the server) but ultimately tediously boring rehash of Trade Wars. The server is mostly just a massive OLTP machine.
Because MS Visual Studio STILL doesn't support it, methinks.