Monday, 29 October 2018

Follow-up To Previous Post - I forbid you from showing me an outer join!

At the risk of repeating myself, and again quoting from Quora … I came across this today:

It still baffles me that even some senior, hands-on and so called technical people in IT, still do not know how to write efficient SQL.

Here is the full quote: - - - - - - - - - - - - - - - - - - - - - - - - - -

What are the pros and cons of having complex SQL queries vs. simple SQL queries, but using other programming languages to handle the complexity? Should I write a complex SQL query to handle everything?
Bill Karwin, author of "SQL Antipatterns: Avoiding the Pitfalls of Database Programming" 

I saw a coworker, a senior Java programmer (with a PhD), struggling to get some code written. He was behind on his deadline. I asked him what he was trying to do and if I could help.
He said he needed data from two tables. He needed all data from the first table and only matching data from the second table. Where there was no matching data, he still wanted the data from the first table, but with nulls for the objects where there was no match in the second table.
“What’s the problem? That’s an outer join in SQL,” I replied.
He said he didn’t know how to use an outer join, so he had spent many hours trying to code the task from scratch using Java. He was fetching all the data from both tables, matching it up, and discarding data from the second dataset that didn’t match. He was trying to make the matching more efficient by implementing some sophisticated sorting algorithm and a B-tree data structure.
“No, really, the database can do that easily, it’ll run faster, require less code, and you’ll only fetch the results of the match. I’ll show you how,” I offered.
His face grew dark, and he literally said to me, “I forbid you from showing me an outer join!
He had invested so much in implementing his data structure that he couldn’t bear to admit he had wasted his time. He would rather finish his pages of Java code, and never know how to do the same task in one line of SQL.
Don’t be that guy. Use the right tool for the job.

Monday, 15 October 2018

Don't put business logic in the presentation layer!

I'm currently working on a short-term contract in Sydney ... and I've already had several run-ins with the IT Manager. Essentially, it can be summarised by the answer below. 

The problem is, that my client wants to do calculations on the data at the presentation layer, in this specific case, in Qlik! 

Now don't get me wrong, Qlik is a great tool, with wonderful looking charts. But as a place to do complex joining of all the data, not right.  What happens when we want to display the same data on something else? Say, for example, a native App? 

The data, and the calcs, need to be copied somewhere else. Currently all the data is being copied into Qlik and then the joins, IF/ELSE statements, date calculations etc .... are all in Qlik. 

As per the answer in the link article below, there is no documentation, and no one else to support it. 

I've suggested building a proper data warehouse using Microsoft SQL Server. And then linking Qlik to the data in the warehouse, as it is very good at doing. But unfortunately, it's not my call.

I think it's mad. But .... the customer is always right, so I'm doing the best I can. 

What do you think? Before you answer ... be sure to read what Andrew wrote below: 

Read Andrew Weishan's answer to Why is SQL in such high demand when I can use Excel and do half of the work, and never have to enter code again? I can literally write a macro and have a button. on Quora