Defending the RDBMS

  • Comments posted to this topic are about the item Defending the RDBMS

  • For all there faults RDBMS's have been tested pretty damn thoroughly over the past decades.  That testing has been in the real world rather than isolated to academia and in ways that I doubt the vendors and inventors ever envisaged.  They have not only survived but  thrived.  They have not been without competition.  They have done so because they work, they are easy to understand and develop.

    I'm sorry, I am really tired of the bleating that they are hard to use.  Try using their predecessors.  If they are so hard to use they how come so many of the NOSQL solutions have chosen to use a flavour of SQL..

    Is data modelling hard?  It can be but then again so can designing software properly.  The problem with simple designs is that their simplicity hides the genius and effort of their creation. 

    There are in-memory databases. Michael Stonebraker's VoltDB springing immediately to mind. springing immediately to mind. Jim Starkey's NuoDB[/url] being another one.

    Would I use an RDBMS in all situations?  No of course not. Document stores work well with forums and surveys, key-value stores work well with web session state, implementing the equivalent of AWS S3 storage buckets etc.

    Dr Lance Gutteridge wants to blame RDBMS.  Blaming RDBMS for complexity in migrating an ERP code base that has descended into a big ball of mud is disingenuous.  Stateful systems will always present a challenge.  Build a data consuming application such as a report on top of any data source and you have created a dependency on that data source regardless of whether it is a JSON file, RDBMS, Avro/Parquet/ORC file on HDFS.

  • Ok, so the first argument would appear to be able to be summarized as "I have no idea what a database really does, or how to use one effectively ... so I'll build my own.  How hard could it be?".
    I have actually seen saner projects with more chance of success on Top Gear, including the one for turning a Reliant Robin into a space shuttle.  For those of you unfamiliar with this (Series 9 Episode 4 - believe it's on Youtube) the end result was a large explosion which took out a sizable chunk of Northumberland.  "what could possibly go wrong?"

    I'm a DBA.
    I'm not paid to solve problems. I'm paid to prevent them.

  • The biggest issues I have seen with relational databases revolve around not understanding the basics, or not taking time to think out the system. Now an honorable mention would be fear of refactoring the database. In short, the problems with relational databases will quickly come back in other forms of data storage. 

    It isn't that I believe that relational databases are the best for every problem. For instance Google has found other systems for indexing the internet. But Google have ever been hired to deal with. I am sure there are many use cases for any database type out there.

  • I'm sorry, I am really tired of the bleating that they are hard to use. Try using their predecessors. If they are so hard to use they how come so many of the NOSQL solutions have chosen to use a flavour of SQL..

    I 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 think a fundamental reason that some object to RDBMs is that they are highly structured and enforce structure when used correctly.

    This is by design. In a sense, they are like our legal system. It's tempting to jump to 'is he guilty or not', and it seems sensible (especially to the young). But the complex structure of legal procedures, evidence and motions, the very formal nature that these things are presented complicates things but provides a level of security and stability. Or likewise with engineering, where any design change cannot be implemented willy nilly, but must be reviewed with all side effects considered.

    RDBMs came out of the need for highly structured, highly predictable, completely unambiguous data management. This is essential in business and finance, 99.99% right is not good enough. On the other hand for something like a Google keyword search, where a few misfires in either direction, strict rules are not needed ando other approaches are probably easier.

    ...

    -- FORTRAN manual for Xerox Computers --

  • I 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.

  • I 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

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Web page script injection
    https://en.wikipedia.org/wiki/Cross-site_scripting

  • GeorgeCopeland - Thursday, September 13, 2018 8:30 AM

    I 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.

    I'm a NoSQL guy. :hehe:

  • Remember the language Forth? You could interpret/compile arbitrary expressions on the fly, including expressions that persistently modified the behavior of the compiler. 

    Wonder what could be injected into that?

    ...

    -- FORTRAN manual for Xerox Computers --

  • I 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.

  • johnk 43251 - Thursday, September 13, 2018 9:40 AM

    I 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:

  • I liked Randolph's counter points to the main article. It reads like marketing for a book by making outrageous statements hoping to draw attention. 

    This topic is so played out. How many times must we hear about SQL becoming obsolete and RDBMS going the way of the dinosaur? Whenever I explore the reasons why someone thinks this I feel that they either don't understand RDBMS or that they know they are wrong but want attention.

    I 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.

  • "You cannot escape it no matter where you run, for wherever you go you are burdened with yourself. Wherever you go, there you are." —Thomas a Kempis

    https://securityintelligence.com/does-nosql-equal-no-injection/
    https://www.owasp.org/index.php/Testing_for_NoSQL_injection
    https://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb.html

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Viewing 15 posts - 1 through 15 (of 31 total)

You must be logged in to reply to this topic. Login to reply