The Relational Database is the Default

  • Stefan LG - Thursday, December 7, 2017 10:00 PM

    The problem is not only that developers don't understand SQL and/or relational databases.
    The simply don't understand the data requirements of the applications they are developing.

    There are obviously many reasons for this, but one of the biggest is time constraint where applications are pushed into the market as fast as possible.
    Little time is spend to understand and create a proper data model, so NoSQL seems like an easy alternative.

    In my experience it's that far too many developers just do not understand data requirements or database design at all and many do not want to know. This is a very serious shortcoming in knowledge and skills because pretty much every application is effectively an interface into a database of some form. Trying to avoid this fact does not help matters, and while there are various toolkits that purport to manage the database side for a developer, just relying on these is a foolish endeavour and for anything beyond a short term and small application will come back to bite you before too long. It's not that the toolkits can't be of use, writing bolierplate access code is both tedious and introduces a wonderful source of annoying and often hard to track down errors, it's the unqualified and unmodified use of them that is such a serious issue. Unless it's a noddy application, it is better to properly design the database structure first and then connect to toolkit to the designed database structure.

    As for me... years back when I was at University I intially tried to avoid all the database modules (it was a modular degree course) however I had a "eureka" moment when I twigged that pretty much all applications are interfaces onto a database of some form therefore good database skills were necessary.

  • Rod at work - Thursday, December 7, 2017 11:24 AM

    I really like this article. However, coming at this more from a developer's point of view, I can understand the attraction of the new and shiny thing. It's fun working with the new and shiny. But, I temper my enthusiasm by remembering what a friend of mine who is a manager at another company said, "Don't tell me that something is cool. Tell me why it will improve what we do." 

     One more thing. Please be patient on us developers because sometimes the desire to do something with some shiny, new, cool tool is because we've seen the job market trend and know that companies are abandoning what we've worked with and moving on to some new tool. Some choices carry along with them impact upon one's career. For myself, I don't chase after all the latest tech fads, but I do look at them and as best I can decide upon what's going to last and what I can focus upon. Then I'll go after that.

    Lots of common sense in this response.
    I think there's a lot of benefit in people being honest about their concerns and the drive for change.  Fear of obsolescence is valid and gets more valid as you get older.
    The trick is to move with the times and not the fashion.

  • Just got to share this.
    A colleague was asked to write a query to retrieve information from a MongoDB database.  Fair enough, but when he came to do so he found that the people had managed to force XML documents into MongoDB collections.

  • Well the data is *there* what's the big deal?

  • GeorgeCopeland - Friday, December 8, 2017 10:49 AM

    Well the data is *there* what's the big deal?

    Pretty much the same insanity as storing CSV, XML or json data in text blob fields in a relational database. Yes, the data is there but good luck getting to it without having to go through ludicrous and inefficient steps.

  • n.ryan - Friday, December 8, 2017 11:08 AM

    GeorgeCopeland - Friday, December 8, 2017 10:49 AM

    Well the data is *there* what's the big deal?

    Pretty much the same insanity as storing CSV, XML or json data in text blob fields in a relational database. Yes, the data is there but good luck getting to it without having to go through ludicrous and inefficient steps.

    Yeah, but those are not the tech fault. It's your fault. There are plenty of ways to use a tool wrong. If you give someone that much freedom, RDBMS or not, it's going to get funky.

    Standard and process exist for a reason. Sometimes we are very lucky enough to have that baked into a tool like say, like a constraint. But a constraint is nothing but a process someone made too.

  • You know how newbies are convinced that DRI can be handled by the app? They are ALWAYS proved to be wrong. Every single time.

    Of course they are. What newbie is going to be able to design a declarative language that describes referential integrity constraints into an app? By definition, if the programmer is able to code to that degree, I'm betting they're no longer a newbie.

  • I really dislike the "it's not web scale" argument against RDBMS.  Amazon, Google, Facebook, Twitter, NetFlix genuinely need web scale technologies which is why they invented their own.
    The majority of companies don't need to worry about web scale and wouldn't find the need even if they had a monopoly in their market

  • @david-2 - I agree. It reminds me about Object Oriented databases. When they first started to gain traction people thought it was the doom of RDBMS. Now it is only used in very niche applications. I think the same about big data solutions: volume, variety, velocity are not typical applications - they are niche solutions.

Viewing 9 posts - 16 through 23 (of 23 total)

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