Has Everyone Forgotten “Keep It Simple, Stupid”?

OK, we all love a clever piece of code to do something a little bit tricky, but has everyone lost sight of the benefits of simplicity?

My case study for the day, a thread on the Oracle forums in which various all_objects, user_objects, connect by, MODEL, xmltable, and pipelined function techniques are suggested for generating a list of days.

Well, my comments are in the thread. Just use a table … that’s why we have them. Keep … it … simple.



7 thoughts on “Has Everyone Forgotten “Keep It Simple, Stupid”?

  1. You can go too far the other way. “Keep it Stupid” is not just slightly simpler than “Keep It Simple, Stupid.” You can guess I’m dealing with a situation where “sets” and “requirements gathering” are foreign concepts, and dbase processing row by row is considered the golden age of databases.

  2. Well there’s truth in that for sure, however the situation that you’re dealing with is not a good example because code for set-based processing is generally more simple than row-by-row processing.

    Come to think of it though, I’m not sure that advocates of some of these dysfunctional methods (row-by-row processing vs. set-based, explicit cursors vs. implicit cursors) even believe that what they are doing is more simple than set-based code. It’s almost like a mentality that, “the harder we work on writing the code, the faster it will run”, or to look at it the other way, “if it’s more simple and convenient, it must ipso facto be slower”. The “golden rule” is that you have to work hard for performance, and it’s simply not true.

    To go back to the original example of generating lists of dates, what irks me about the exotic methods is that they may outperform a selection from a table in a simple query, but for more complex queries the cardinality estimation issues are promoters of performance problems. More complex, more prone to bugs, more version dependent, more performance issues — use with extreme caution.

    • There’s a fun song by The Offspring title Self-Esteem.

      There’s a line, “The more you suffer, the more it shows you really care, right?”

      We just had that happen here. Hired new consultant to work with a Workflow product. He wanted the schema owner username and password…

      “OK, I’ll bite, why?”
      “So I can query my workflow back out.” Sayeth the consultant.
      I ask, “Did you read the friendly manual?”
      “Did you know there’s an entire API written to make it simple and documented?”
      “Can you spell API?”

      I have no doubt if he was able to obtain a username and password, he would have built his own super-duper API that was 2% faster than the vendor provided one and would break catastropically the day after he moves on when we upgrade the app to the next point release.

  3. Pingback: Log Buffer #105, A Carnival of the Vanities for DBAs

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s