September 13, 2018 at 11:40 am
I saw the first article that set off this back-and-forth a couple weeks ago (gave me quite a chuckle). The scientific community has a description for ideas like it: "not even wrong".
September 13, 2018 at 1:06 pm
cs_troyk - Thursday, September 13, 2018 11:40 AMI saw the first article that set off this back-and-forth a couple weeks ago (gave me quite a chuckle). The scientific community has a description for ideas like it: "not even wrong".
This professor better plan on retreating to a remote cabin in the woods, because he has ticked off the wrong people. :angry:
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 13, 2018 at 2:49 pm
Jeff Mlakar - Thursday, September 13, 2018 10:51 AMI remember in the late 1990's when Object Oriented Databases were supposed to make RDBMS extinct. Now it is NoSQL databases. Both are truly niche techniques for special circumstances. The fact of the matter is that SQL will be around indefinitely because it is so easy to learn / use and RDBMS is a great solution for the vast majority of persistent data storage and concurrent utilization needs.
LOL, I remember those too. Oracle really dove into that space for a while, but as people tried to use OODB, they found that every system you could model in OODB could be modeled as easy or easier in RDB, but not every system that could be modeled in RDB could even be modeled in OODB.
Fortunately I realized pretty early on it was just another fad.
September 13, 2018 at 3:44 pm
xsevensinzx - Thursday, September 13, 2018 8:05 AMI assume you mean "easy" here? I mean, a lot of ties to the fact that so many people don't want to learn something new. the community is notorious for having people who don't want to budge from the tools they use rather than adapting something new. This is NoSQL's way of trying to nudge them to using it because so many have complained they do not want to learn an OO language just to query the database.
I don't think it's a case of not wanting to learn an OO language. It's a case of not wanting to learn a new method of querying for every single different DB. I would also question the quality of OO design out in the wild. I've seen too many codebase that look like the "before" example in the Clean Code book or a challenger for a medal from thedailywtf.com.
if SQL was a musical instrument it would be a piano. Easy to learn, hard to master, sadly not as portable as you would hope
September 13, 2018 at 4:38 pm
David.Poole - Thursday, September 13, 2018 3:44 PMI don't think it's a case of not wanting to learn an OO language. It's a case of not wanting to learn a new method of querying for every single different DB. I would also question the quality of OO design out in the wild. I've seen too many codebase that look like the "before" example in the Clean Code book or a challenger for a medal from thedailywtf.com.
if SQL was a musical instrument it would be a piano. Easy to learn, hard to master, sadly not as portable as you would hope
Sure, that makes sense. But doesn't change the fact that's why they have put so much emphasis on that and Python lately to try to get people to use soemthing simplier to learn or things they already know to use the tool. I mean personally, I don't see why this didn't happen first. But then again, they were really appealing to the programmers more than the DBA's from what I can tell. Then they realized they have to appeal to both.
September 14, 2018 at 12:44 am
I think that article is nothing else than a marketing stint for someone trying to sell some C-Level book. If you're happy with NoSQL or even just Flat Files (arguably Hadoop is a Flat File stretched database) then be so.
However I don't think RDBMS will disappear, too many KPIs around businesses which in some sort of way might require fire-proof relations within their data.
September 14, 2018 at 3:18 am
The author conflates, among other things:
1) relational database theory,
2) SQL (the language)
3) relational database *management systems*
4) applications/frameworks that use these RDBMS's
into one big thing he calls a 'relational database'. This is just lazy.
His solution to the perceived 'problem' of 'the relational database', is:
1) Buy his book that explains how all enterprise systems except his are flawed.
2) Dispatch with a database management system, and have the *application* 'persist' the data to a flat file. The implication along the way is that he has no database, when in actual fact, he does have one, just not a relational one.
He doesn't like RDBMS's, in part because (he argues) they were designed to compensate for the limitations of 1970s memory and hard drive technology. Ignoring the usefulness of relational theory for modelling data, the usefulness of RDBMS for managing data separate from the applications that create and consume the data. And ignoring the fact that, while yes, RDBMS's were originally
I looked through a few of his articles, and was unable to find any discussion about how his 'not database' would be queried/reported on in an ad-hoc, general-purpose way.
To be fair, I think his 'trial of SQL' has some merit - there's a lot about SQL that I don't like and find arcane - there's huge room for improvement. But problems with SQL as a language have little to do with relational theory and the underlying mechanics of RDBMS's.
To have more credibilty for me, the article would need to:
1) start with some well-reasoned 'rational' (see what I did there) arguments about real problems, instead of an FUD-ish rant about irrelevant issues.
2) provide real evidence to support his thesis: demonstrate that his solution out-performs and out-persists a similar size relational database, maybe with a live web site people could experiment with - heck if he can write whole ERP systems like this, a small demonstration environment with a related github repo should be easy.
3) Not end with a 'buy my book' or 'read my other articles with similar unsupported with evidence rants'.
September 14, 2018 at 3:45 am
Eric M Russell - Thursday, September 13, 2018 8:58 AMI don't know why SQL injection is presented as a fundamental flaw of relational databases. Code injection is a much broader security issue that can target all tiers of an IT system, and it really boils down to programmers and administrators failing to take proper precautions.Buffer injection
https://en.wikipedia.org/wiki/Buffer_overflow
JavaScript injection
https://docs.microsoft.com/en-us/aspnet/mvc/overview/older-versions-1/security/preventing-javascript-injection-attacks-cs
PDF document injection
https://security.stackexchange.com/questions/8113/how-to-inject-executable-malicious-code-into-pdf-jpeg-mp3-etc
Thumb drive injection
https://learn.adafruit.com/the-foul-fowl-keyboard-injection-payload-gemma-m0/overview
Network injection
https://en.wikipedia.org/wiki/Man-in-the-middle_attack
Particularly compounded by the fact that the author appears blissfully unaware of the simple fact that SQL <> Relational. IDMS (IDMS-X) and MUMPS (Certainly in the "OODB" Graph) now have SQL interfaces - as indeed does Excel. Presumably he thinks these are now relational too
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
September 14, 2018 at 3:47 am
GeorgeCopeland - Thursday, September 13, 2018 8:30 AMI have always tried to be diplomatic, but for once, please let me be frank. The NoSQL people are communists. You explain the issues to them, and their response is always that nobody has ever tried *real* NoSQL.
Possibly the most peculiar definition of Communism I have ever seen.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
September 14, 2018 at 3:50 am
xsevensinzx - Thursday, September 13, 2018 9:44 AMjohnk 43251 - Thursday, September 13, 2018 9:40 AMI have 34 years experience in technology administering and developing in environment using database systems base upon the Codasyl (Networked), Relational, Post Relational Model and even ISAM files.
If problems arise, it is because of poor understanding of the actual business data structures and/or poor application design. Dr. Lance Gutteridge misses that entirely in his articles.But, if there is a solution that is better for poor application design, doesn't that make it a better tool than one that needs the best application design to function?
Mind blowing, I know. :laugh:
No. Crap design doesn't work as required. That's why it's crap design. This is one of the few Universal Truths and no amount of snake oil, no matter how it's dressed up, can change that.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
September 14, 2018 at 6:57 am
andrew gothard - Friday, September 14, 2018 3:47 AMGeorgeCopeland - Thursday, September 13, 2018 8:30 AMI have always tried to be diplomatic, but for once, please let me be frank. The NoSQL people are communists. You explain the issues to them, and their response is always that nobody has ever tried *real* NoSQL.Possibly the most peculiar definition of Communism I have ever seen.
I think what he meant to say is that many NoSQL advocates are ideologues, which would be accurate.
ideology (noun): the body of doctrine, myth, belief, etc., that guides an individual, social movement, institution, class, or large group.
ideologue (noun): a person who zealously advocates an ideology.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 14, 2018 at 10:01 am
Chris Harshman - Thursday, September 13, 2018 2:49 PMJeff Mlakar - Thursday, September 13, 2018 10:51 AMI remember in the late 1990's when Object Oriented Databases were supposed to make RDBMS extinct. Now it is NoSQL databases. Both are truly niche techniques for special circumstances. The fact of the matter is that SQL will be around indefinitely because it is so easy to learn / use and RDBMS is a great solution for the vast majority of persistent data storage and concurrent utilization needs.LOL, I remember those too. Oracle really dove into that space for a while, but as people tried to use OODB, they found that every system you could model in OODB could be modeled as easy or easier in RDB, but not every system that could be modeled in RDB could even be modeled in OODB.
Fortunately I realized pretty early on it was just another fad.
I've sort of come to the exact opposite conclusion, that objects in general are a superset of what can be efficiently modeled in relational databases. And if you can efficiently persist objects into databases then the advantages very well may propagate into the database. What you LOSE when you don't use RDBMS technologies are all the programmer efficiencies that you get from the relational model.
I'd love to see some citations about RDBMS's having systems that couldn't be duplicated in OODB's, once programming costs are eliminated from the equation. Do you have some citations there? I don't mind being corrected on this one!
September 14, 2018 at 10:51 am
Ryan C. Price - Friday, September 14, 2018 3:18 AMTo be fair, I think his 'trial of SQL' has some merit - there's a lot about SQL that I don't like and find arcane - there's huge room for improvement. But problems with SQL as a language have little to do with relational theory and the underlying mechanics of RDBMS's.
I agee. SQL is a horrible language, especially for DDL, but the underlying system works really well for many problems, including handling OLTP and simple OLAP type queries efficiently.
September 14, 2018 at 3:53 pm
andrew gothard - Friday, September 14, 2018 3:50 AMNo. Crap design doesn't work as required. That's why it's crap design. This is one of the few Universal Truths and no amount of snake oil, no matter how it's dressed up, can change that.
Unfortunately, that's not always the case, getting something to change is not always easy. This includes getting the application to conform or even getting the business process to conform.
September 21, 2018 at 7:47 am
patrickmcginnis59 10839 - Friday, September 14, 2018 10:01 AMChris Harshman - Thursday, September 13, 2018 2:49 PMLOL, I remember those too. Oracle really dove into that space for a while, but as people tried to use OODB, they found that every system you could model in OODB could be modeled as easy or easier in RDB, but not every system that could be modeled in RDB could even be modeled in OODB.
Fortunately I realized pretty early on it was just another fad.I've sort of come to the exact opposite conclusion, that objects in general are a superset of what can be efficiently modeled in relational databases. And if you can efficiently persist objects into databases then the advantages very well may propagate into the database. What you LOSE when you don't use RDBMS technologies are all the programmer efficiencies that you get from the relational model.
I'd love to see some citations about RDBMS's having systems that couldn't be duplicated in OODB's, once programming costs are eliminated from the equation. Do you have some citations there? I don't mind being corrected on this one!
Purely an subjective view, of course, but in my experience the limiting factor is quite simply who's designing it.
I'm not quite sure how this is reflected outside the UK, but I recently asked a Maths teacher mate about the teaching of the subject. Apparently, up to the age of 16, set theory and anything but the most rudimentary data manipulation (in terms of Matrix Algebra, for example) simply aren't touched. Even after this (where Maths is optional) it seems somewhat cursory. The passage of time can play tricks, but up to that age I do recall being introduced to both set theory (mostly in the form of Venn diagrams) and matrix algebra. It was also quite well covered at A level (16-18). As a result, I had a grasp of these from a youngish age. Now if these are now wholly absent from the education of anyone who has not studied Maths at 16+, it's hardly surprising there's so much ignorance and failure to grasp even extremely basic relational principles.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
Viewing 15 posts - 16 through 30 (of 31 total)
You must be logged in to reply to this topic. Login to reply