July 15, 2014 at 2:30 pm
andrew gothard (7/15/2014)
Phil Factor (7/15/2014)
@patrickmcginnis59Yes, it is certainly possible to have a NoSQL database that handles ACID properly. It just surprises me that some don't. As I understand the Bitcoin exploit, I can't see how it would have happened with multi-user RDBMS. This is, after all, a problem that is intrinsic to any trading or banking system. The links are well-worth reading if you're interested in the details.
"We handle all that in the app using the ORM because business rules shouldn't be in the database layer and just use it as a dumb datastore, <<IT'S BEST PRACTICE>>" perhaps?
The Bitcoin failures were spilled milk. Most people have never heard of Bitcoin and very few have ever used it, so it's geek tech news not primetime TV news. However, the day will come when we'll see a major catastrophic failure at a real bank or online retailer, and then we'll see backpeddling on the NoSQL hype.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 15, 2014 at 5:42 pm
Andrew..Peterson (7/15/2014)
If you give a mechanic a new tool, does he dump all his other tools? No, but it seems developers tend to view the latest new database widget as the replacement for all the others. Anyone remember object databases?
Here we go grouping everyone all into one large group. I can agree that it seams MANY developers tend to view the latest new database... but I cannot agree that the implied "all" in the "but it seems developers tend ..." is anywhere close to correct.
I like a large number of developers come from the old school and would like to see the boat float before we invest in the "latest/greatest/fastest ever" whizbang that comes along.
M.
Not all gray hairs are Dinosaurs!
July 15, 2014 at 7:17 pm
I'm not sure if the post is making fun of BitCoin, the programmers, the business people who signed off on the programmer's design decisions, the programming philosophy of eventual consistency, or the back-end database.
Who's to blame? Because the last thing I'd be blaming is the storage back-end.
July 21, 2014 at 10:04 am
It is a very simple case of poor consideration of real requirements. The cause? Could be many things from not attempting to elicit requirements to simply ignoring them.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
July 21, 2014 at 10:44 am
It's interesting that developers on the various "NoSQL" platforms are now focussing their efforts on implementing SQL language interfaces. Apparently when it came time to start capitalizing on their inventions and paying the bills, they discovered that the corporate world isn't interested in learning how to write code in some geeky new syntax like MapReduce.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 21, 2014 at 10:47 am
Probably an issue of job security vs ease of use.
Not all gray hairs are Dinosaurs!
July 21, 2014 at 11:17 am
Eric M Russell (7/21/2014)
It's interesting that developers on the various "NoSQL" platforms are now focussing their efforts on implementing SQL language interfaces. Apparently when it came time to start capitalizing on their inventions and paying the bills, they discovered that the corporate world isn't interested in learning how to write code in some geeky new syntax like MapReduce.
I don't think that SQL is that bad a language, and I also don't think its too late for anyone to learn SQL. Heck its even possible that an SQL statement could be translated into a map reduce job. I think with some of the larger NoSQL sites it makes darn good sense to automate query construction, and thats SQL's strong point, it by definition doesn't necessarily specify how to put query results together, and I'm betting putting together a query for some of those big NoSQL databases is a pretty nontrivial job thats ripe for automation, so why not use a familiar syntax for the job?
July 21, 2014 at 11:36 am
patrickmcginnis59 10839 (7/21/2014)
Eric M Russell (7/21/2014)
It's interesting that developers on the various "NoSQL" platforms are now focussing their efforts on implementing SQL language interfaces. Apparently when it came time to start capitalizing on their inventions and paying the bills, they discovered that the corporate world isn't interested in learning how to write code in some geeky new syntax like MapReduce.I don't think that SQL is that bad a language, and I also don't think its too late for anyone to learn SQL. Heck its even possible that an SQL statement could be translated into a map reduce job. I think with some of the larger NoSQL sites it makes darn good sense to automate query construction, and thats SQL's strong point, it by definition doesn't necessarily specify how to put query results together, and I'm betting putting together a query for some of those big NoSQL databases is a pretty nontrivial job thats ripe for automation, so why not use a familiar syntax for the job?
That's exactly what HivSQL does, it's an ODBC compliant provider that translates SQL into MapReduce. HCatalog is a meta-data service that translates physical file locations into logical table names.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 21, 2014 at 11:57 am
Eric M Russell (7/21/2014)
patrickmcginnis59 10839 (7/21/2014)
Eric M Russell (7/21/2014)
It's interesting that developers on the various "NoSQL" platforms are now focussing their efforts on implementing SQL language interfaces. Apparently when it came time to start capitalizing on their inventions and paying the bills, they discovered that the corporate world isn't interested in learning how to write code in some geeky new syntax like MapReduce.I don't think that SQL is that bad a language, and I also don't think its too late for anyone to learn SQL. Heck its even possible that an SQL statement could be translated into a map reduce job. I think with some of the larger NoSQL sites it makes darn good sense to automate query construction, and thats SQL's strong point, it by definition doesn't necessarily specify how to put query results together, and I'm betting putting together a query for some of those big NoSQL databases is a pretty nontrivial job thats ripe for automation, so why not use a familiar syntax for the job?
That's exactly what HivSQL does, it's an ODBC compliant provider that translates SQL into MapReduce. HCatalog is a meta-data service that translates physical file locations into logical table names.
I worked a bit with Unidata which wasn't very relational at all (I think its one of the so called "multi valued" databases), or rather, the vendor said it was "nested relational". One of the interesting things was its odbc driver, a unidata table could have a "field" that could itself be a table (thats why it was sometimes called "nested relational"), and the odbc driver could make it appear as another table, and when queried with a join to its containing table, pretty much translated into a regular read of each record then cycled through its contained record in that field. The closest I could think it looked like was something like Oracles "repeating groups" (VARRAY).
July 21, 2014 at 11:57 am
From the article...
It is very difficult to explain in simple terms why the principles of relational database are so important. To be able to safely determine whether a system requires a relational database, or can alternately, be entrusted to a NoSQL startup, requires a great deal of expertise.
I think this is the fundamental problem with many systems. There are two major problems that manifest themselves as a single problem...
They want it real bad... and get it that way.
They have the wrong people doing the planning because a lot of folks think that "experts" are too expensive and that anyone should be able to do such a "simple" thing correctly. Just think of the number of people that mistake avoiding pre-optimization for writing good code.
--Jeff Moden
July 21, 2014 at 12:53 pm
patrickmcginnis59 10839 (7/21/2014)
Eric M Russell (7/21/2014)
patrickmcginnis59 10839 (7/21/2014)
Eric M Russell (7/21/2014)
It's interesting that developers on the various "NoSQL" platforms are now focussing their efforts on implementing SQL language interfaces. Apparently when it came time to start capitalizing on their inventions and paying the bills, they discovered that the corporate world isn't interested in learning how to write code in some geeky new syntax like MapReduce.I don't think that SQL is that bad a language, and I also don't think its too late for anyone to learn SQL. Heck its even possible that an SQL statement could be translated into a map reduce job. I think with some of the larger NoSQL sites it makes darn good sense to automate query construction, and thats SQL's strong point, it by definition doesn't necessarily specify how to put query results together, and I'm betting putting together a query for some of those big NoSQL databases is a pretty nontrivial job thats ripe for automation, so why not use a familiar syntax for the job?
That's exactly what HivSQL does, it's an ODBC compliant provider that translates SQL into MapReduce. HCatalog is a meta-data service that translates physical file locations into logical table names.
I worked a bit with Unidata which wasn't very relational at all (I think its one of the so called "multi valued" databases), or rather, the vendor said it was "nested relational". One of the interesting things was its odbc driver, a unidata table could have a "field" that could itself be a table (thats why it was sometimes called "nested relational"), and the odbc driver could make it appear as another table, and when queried with a join to its containing table, pretty much translated into a regular read of each record then cycled through its contained record in that field. The closest I could think it looked like was something like Oracles "repeating groups" (VARRAY).
People do that, with limited success, in SQL Server and Oracle using XML columns.
http://technet.microsoft.com/en-us/library/ms191497(v=sql.105).aspx
SQL Server's Column Sets are also a form of XML datatype, except the columns are not nested.
http://msdn.microsoft.com/en-us/library/cc280521(v=sql.105).aspx
But MongoDB probably handles nested XML documents better, because the data and index structures are optimized for it.
I believe that going forward most enterprise database environments will be like a three ring circus with the relational database working in conjunction with something like Hadoop for bulk archival and analytics and MongoDB for document stores. Folks may start loving their SQL Server database even more, once it can focus on what it does best and stops being used like a jack of all trades.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 28, 2020 at 8:41 am
This was removed by the editor as SPAM
October 29, 2020 at 7:54 am
This was removed by the editor as SPAM
Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply