"I've isolated the bug to a database query"
thedailywtf.com
thedailywtf.com
I hate being afraid of code. I spent a day with it, got to understand it, then rewrote it as a couple of queries and some Java code, whereupon it took about five minutes to run.
[... then there was the guy who implemented bitwise AND and OR by precomputing some 65536 entry tables. Wow. Why do I find all the really howling bad stuff so close to databases?]
That stuff ends up in databases because on your average team the knowledge of databases drops dramatically when you get past selects and maybe left joins. I worked with a few developers who wrote and lived with queries that were taking 30 seconds each to run on their local machines because they couldn't imagine how to fix them and just waited for me to get assigned to the project in a week or two so I would fix it. They just kept raising the timeout values until the pages rendered. The problem was simple in that they were accessing a table with 30 million rows without using any index at all so changing it to use the clustered index made the query return almost instantly.
I've seen similar things where people come up with crazy ways of doing your most basic database tasks.
Don't lord it over them, explain.
Other devs on my team had real problems with it - they were stuck and found it really difficult to "think in sets." They kept asking me about how to use cursors to go through data . . . heck, they may even have been right from a clarity and maintenance perspective.
But the object-oriented part of my brain has apparently been excised by spending so much time fishing (SQL). So now I have too many fish questions in that direction.
This parameter saved it all "innodb_buffer_pool_size = 768M" ... how am I supposed to know that Rails creates InnoDB by default, i thought MySQL default was always MyISAM.
In real RDBMS systems, tables can be clustered (index organized in Oracle-speak) or not, nested or not, in different tablespaces, with many different parameters that do not change the semantic of DML/queries but change the performance significantly.
With this in mind my boss mentioned one of our sites was "dying on its arse." It was hammering the slow query log, pages could take 10, maybe 20 seconds to load.
Turned out there were NO indexes at all. Maybe the odd primary key from the default CMS install (which was by no means database efficient). So we sorted that and that sorted out the immediate speed issues.
Of course, it went without saying that a poorly constructed schema must be related to a poorly constructed query or two. We were actually wrong. It was more like a query or twenty.
The submission of one form was done field by field. There was an UPDATE query constructed for each field and processed there and then, on a form with at least 12 fields. There was a comment above, "We have to do it this way. Trust me." As far as I could tell they didn't know how to dynamically build a query.
Further along, different update queries were performed by first deleting the record, and then re-inserting it with one of the fields updated.
I never quite got as far as that. There was no comment anywhere about the reasoning for such a strange approach.
I think some developers don't bother figuring it out because they think there are better things to do than optimise your code.
//We have to do it this way. Trust me[this comment removed and replaced with the "Trust me" line, because maybe multi-line comments are breaking things today...]
Because the database and queries against were were coded as an afterthought.
Because the programmers ran all the db access tests against tables with 4 rows of data when the customers would windup with 100 million rows in production.
Because most undergrad education around databases is poor and antiquated. Plus, it is not SQL focused - much time is spent on talking about data modeling. Not wrong, but not often helpful in practice.
Because DBA's are (rightly) focused on making sure your db is properly backed up, replicated, and fault-tolerant. They may not even understand SQL queries beyond the basic one table select.
Because the users will force data into the systems that the developers never anticipated.
Because db jobs are segregated by product for development. If you've done SQL coding on Oracle for the last 10 years, good luck applying for a job doing SQL coding on MS SQL Server.
Because SQL hacking doesn't get much respect. I've been in job interviews where deep into the process they ask me a question with data in two tables that requires an outer join. And answering correctly differentiates you significantly from other applicants. I guess it is the "fizz buzz" of SQL these days . . .
I've once had a guy I worked with ask for help when he was with a new company. I told him to look at the query plan. He replied, "Yeah, but that doesn't tell you much."
Relational databases are oft-misunderstood and underestimated time and time again. Where are the Codds of yesteryear?
select
sp.Name,
sum(s.Amount) as TotalSales
from
SalesPerson sp
left join Sales s on
sp.SalesPersonKey = s.SalesPersonKey
group by
sp.Name
order by
TotalSales desc
Left joins (and full outer joins) are plenty useful and I use them almost daily. Care to explain what you mean?
select
sp.Name,
sum(s.Amount) as TotalSales
from
Sales s
RIGHT join SalesPerson sp on
sp.SalesPersonKey = s.SalesPersonKey
group by
sp.Name
order by
TotalSales desc
I'm guessing it's all about what people have experienced. I have been coding against RDBMSes since my first job while still in college. I have even read Celko for fun at one point :)
IMHO, learning the hard parts of SQL only come from experience with particular RDMSes and dealing with large datasets. For example, knowing that the only way to get a query to run against a large Teradata table without running out of spool space is to create and use temp tables only comes as a result from trying to run the query.
It's the fastest way for them to solve a problem in terms of development effort, but it often leads to poor solutions and poor SQL.
So SQL is just as easy to pick up as anything else, but you're going to be horrible at it at first and need to get past the mental block of seeing something so different conceptually to "normal" programming.
The result is that many developers will do selection and sorting algorithmically (taking the bugs and LOC that entails), instead of using declarative SQL.
I have worked at places were the database is just seen as something in the periphery, that you just have to deal with since Oracle is a requirement from customers. Its sick really when you think about it.
Im disappointed by many of the comments here that basically is "SQL sucks because I don't understand it".
I have no formal CS schooling, so thinking in sets is far from basic - I often have to stop myself from thinking in iteration. Reading Celko's "Thinking in SQL" book is in fact helpful (although why does he keep yelling at me? and what's FORTRAN?)
But it's very foreign and black-box-y to many programmers, and a tiny bit of SQL voodoo, like a tiny bit of Javascript voodoo, will get you a very long way with very poor performance.
select *
from foo f, bar b
where f.baz = b.baz (+)
select *
from foo f, bar b
where f.baz (+) = b.baz
I just searched the full (Oracle) sql codebase of the project I'm working on, and it seems that there is no clear winner in the "outer join" vs "(+)" battle (outer = 46%, (+) = 54%). There is no code style requirement for joins.
edit - I tried this out and right now cannot get that error, so not sure where I got that idea from.
Where a.client_id = c.client_id
And a.client_id = b.client_id (+)
And c.client_id = b.client_id (+)
It's very common to want to LEFT JOIN two tables, and then see specifically which ones on the left had no corresponding record on the right. But the old way cannot specify the JOIN criteria separately from the filter criteria, so we can't express the query.
For example, in my current database, I might do the following to see what categories are not represented by any products:
SELECT *
FROM Products.Category AS c
LEFT JOIN Products.Product AS p ON c.CategoryId = p.CategoryId
WHERE p.ProductId IS NULL
SELECT *
FROM Products.Category AS c
, Products.Product AS p
WHERE c.CategoryId = p.CategoryId (+)
AND p.ProductId IS NULL
Also, changing schema tends to be easier too as you can often just delete the JOIN line if you've been coding consistently instead of having to pick through the WHERE clause on more complex queries.
In the end though I guess a lot of it comes down to what you're used to, though I have been exposed to both and would definitely be in the JOIN camp and help utterly destroy you evil ,s if we had to have a worldwide battle to decide the fate of SQL kind.
Let's modify the query slightly, to retrieve all categories are not represented by any products from a particular manufacturer. The standard syntax would look like this:
SELECT *
FROM Products.Category AS c
LEFT JOIN Products.Product AS p ON c.CategoryId = p.CategoryId AND p.ManufacturerID = 123
WHERE p.ProductId IS NULL
SELECT * FROM Products.Category AS c , Products.Product AS p WHERE c.CategoryId = p.CategoryId (+) AND p.ProductId IS NULL AND p.ManufacturerID = 123
http://www.codinghorror.com/blog/2007/10/a-visual-explanatio...
Hope that helps!
[1] Though I apparently did well enough to get the job, I felt as if I utterly failed the interview.
On the one hand we make-believe that all you need to know is how to sling code and as long as you can somehow get your data into the database and out, then you've done your job as a developer. I think that's bullshit. No one would use your application without the data, so the database is as much of your responsibility as any other part of the system. You should know how to use it well and should take responsibility for its quality.
On the other hand, there are things that belong in application code, rather than, for example, in a stored procedure. Most things you could do with a stored procedure probably belong in application code. The app is where the business logic is, the database is where the data is. As a DBA you aren't doing your job right if you feel OK about implementing business rules in SQL. It's much poorer at expressing intent than an OO language would be, it's less readable, and doubles the number of places you need to look for domain logic.
The WTF's go both ways.
You are right that application developers should not be ignorant of databases, and DBAs should not be ignorant of what application developers are doing. All too often, this is the case.
However, the point when people came to think of application and database development as two separate things was the origin of databases themselves, and arguably one of the most important historical points in computer science itself. The notion that data has a life outside of any given application, and that it deserves itself to be managed, was and is incredibly powerful.
My take is that the principles of database engineering only make intuitive sense at scale.
If every programmer started their career as an assistant DBA at a web host with a lot of traffic, or a data warehouse with a ton of transactions and report generation going on, or a company where lots of different groups were developing client code against the central database, every programmer would be inspired to understand databases.
As it happens, programmers start their career building little apps with one client at a time and a handful of data. And many of them finish their career building such apps, because they are very handy. And these programmers may never feel a burning need to know how databases perform with large datasets, or a huge stream of colliding transactions, or a mission-critical data integrity and safety requirement, or a variety of clients all trying to generate complex reports.
Sigh... This again. Out here in the real world, we have databases with a hundred apps connected, with tens of thousands of concurrent users, and these apps are written in a dozen or more languages, there's COBOL, VBA, C++, Java, Python... There's green screens, desktop apps, websites, embedded devices...
The ONLY way to have consistent, enforced business logic, from ANY application in ANY language (even people executing SQL directly) is to do it in stored procedures. Doubles the number of places? Your way is 100x the number of places. Little websites with one application running on one database are not really representative of serious database use.
Ho ho ho. Website experience doesn't translate to real database work.
As to the rest of your response, I don't mean to be rude but you're simply rambling. Obviously with a legacy system you work with what you've got, but the point is what you would choose if you had a brand new system and needed to make the call today. Choice of language depends on system requirements as we all know.
I really feel uncomfortable about all this posturing. I'm all for discussion, but if you honestly consider me a moron for saying what I have, you shouldn't have any interest in responding. Participating in a discussion merely to dismiss (and disparage) the other party is pointless and boring. Down-vote and move on.
It must be nice to only work on greenfield projects, but as I keep saying, it is not experience that transfers to large scale development efforts, which span decades and continents. If you spread this kind of misinformation, you create more problems than you solve, when the "business logic" is in a hundred places and no-one knows what bit of the system does what. Sure SQL isn't the perfect language, but it is the de facto lingua franca. And there is no "the app" for the business logic to live in. There are a hundred apps, each of which is a piece of "the app".
And if we're pointing fingers, it was you who asserted that a DBA who sees the big picture (funny how every developer thinks theirs is the only app in prod, when they are really in a cast of thousands) doesn't know how to do their job. Show a little humility and you will learn.
I am taking a database management class this semester. Its awful. We spent over half the semester drawing diagrams. Just last week we started working with actual SQL.
See also Linq, you get some really crazy stuff written in Linq because people don't really understand it.
(On the other hand, I've rarely found query planners, even for Oracle, to be as magical at optimizing as one might hope, so maybe that's why.)
If this is wrong and goes against "DB best practices" then I guess this answers my question about where the howlers come from.
[We had a project under development. At some point, and an utter surprise to the team, an Oracle consultant showed up one day and said, "I'm here to tune your database."
"Huh?"
And he did. Against a half-built system with a schema we were still designing, he "optimized" our queries and determined buffers sizes and whatnot, and then he went away.
Apparently the people in Sales were panicked that we had a database under development that we hadn't yet made plans to tune, so they had hired a guy to come in and fix things.
We tossed all of his scripts and rolled back everything he'd broken, and continued coding. Total waste of money.
Databases are a weird confluence of the power-mad, the knuckle-draggers, the money-grubbers, and a few techies who know what the heck they're doing.]
At least that's my experience.
The longest query I have ever written I thought was approaching unmaintainability at about 100 lines, but I can sit down and digest it without too much effort. I have however spent a week debugging a query that was three times that long. I think the time to understand starts increasing with the square of query length...... 100 lines may not take too long to understand, but 200 lines takes 4 times as long, 1000 lines takes 100 times as long, etc.....
At least my experience is that even well written SQL starts becoming a bear really fast when over 100 lines ling.
I have seen a few of those, but you also have to include not only stored procedures but also table layout etc. Things like "if I don't define my foreign keys, I can use a foreign key to reference rows in EITHER table a or table b!"
And then of course when you write sprocs against that mess, you get more messes.
The thing is that databases are fundamentally math engines with some extra services tacked on. This means that designing databases is ideally a mathematically sound representation of your data not specific to your application, and the database queries bridge the gap. Most developers don't understand this though and so as the application changes, you get big messes.
Now, obviously the above is an ideal which really can't be met in most cases. However the closer one is, generally the more ideal the situation, and most apps are really far from it.
BTW, as a counterexample, I saw one developer figure out how any invoices were closed by retrieving millions of them from the db and checking in Perl. All for the want of a HAVING clause.... Needless to say while this worked ok for small amounts of data, it failed with large sets.
I've made a few SQL errors in my past that failed on large sets, but fortunately I was working against large sets, and they failed miserably, and we had to figure out why. I got good advice from an expert and fixed the problem. In many ways keeping queries separate, and focusing on readability/code standards helps a great deal I think.
Once you've visually decomposed it, you'd physically decompose it by splitting it inside-out. Then proceed to understand and debug inside-outwards.
Not fun, but not impossible. Just a huge pain in the ass. Making it more fun would be a database with bad RI, nulls, and duplicate data all over the place. Don't get me wrong -- from looking at the image it definitely looks like aspirin will be required. :)
It's been a while since I last deep-dove in a complex database, so I don't have any other examples handy. Sorry. Maybe somebody else can pick up the thread. I remember reviewing a bunch of them several years ago -- these tools have been around for a long time.
You cannot do any better than have the DB tell you exactly what it is going to do with your query. Then you can experiment with changing / adding / removing clauses and see how it would affect the query plan produced by EXPLAIN.
For example if EXPLAIN says the query would generate a temp table you could often achieve improvement by managing the same temp tables explicitly. Many times you can get a huge performance lift by using a "group by index". You could identify and rewrite un-indexed table scans too.
I've found lots of other "unobvious" optimizations that cut down queries that ran for days or hours to minutes or seconds.
Here are a few references to get started-
1) http://dev.mysql.com/doc/refman/5.5/en/execution-plan-inform...
2) http://www.mysqlperformanceblog.com/2006/07/24/extended-expl...
3) http://www.mysqlperformanceblog.com/2010/06/15/explain-exten...
First, both the syntax and the way querying is generally presented in textbooks, lead you to think that your task when querying is to display one unnamed table. The author objects to each of those four words.
Second, many people have found querying with SQL terribly difficult. Even experts find SQL hard to create and read. Do not be surprised if an analyst struggles to understand his/her own SQL. It is impossible for users to understand any but the simplest SQL.
Third, SQL practice suffers from the notion of a "correlated query" -- which has a monolithic subquery that is executed repeatedly via looping, once for each value of a candidate row picked by an outside SELECT.
The book has much more to say on the topic of SQL before going on offer relational algebra (built on top of SQL) as a n alternative.
In fact, due the lack of side effects it's much easier to do than with procedural code.
I didn't know about the WITH statement. Thanks for enlightening me.
The real issues with SQL come down to the fact that it is an imperfect representation of relational math, and then also the dreaded ambiguity regarding NULLs.
The problem with NULLs is that NULL is used to refer to two very distinct conditions. In one case (outer joins) they are used to refer to a NULL set. In another, unknown values. These really should be distinct values.
I have a very simple rule for myself - "if a user of the application is concerned about a certain attribute or state an element (e.g. person, truck, plane) is in, then a report will be required showing all elements with that attribute or state."
If your database design cannot support that rule, then trouble will happen and you will have serious performance problems.
To give a simple example, suppose you are running a group of storage garages. You have a table with all your customers, a table with all your storage units, an assoc table joining customer and units with active flag + date of start, and a table with all your payments. Good enough to do transactions and figure out for a unit if they are payed up.
On the other hand, writing the report to tell who hasn't paid is going to be kind of a pain. It is a simple example, but not much different from what you find in large systems.
If it's the former, then sure: you need to be able to model all these things properly. If it's the latter, then I'm not so sure. The SQL to create that sort of report is going to be non-trivial, but it shouldn't be overly complex for someone who knows what they're doing, and if you have the correct indexes it shouldn't take very long to run either.
If you want to start doing all sorts of fancy data warehouse slicing and dicing, you're usually better extracting daily (or more/less frequent depending on needs) dumps of your transactional database into a different structure more suitable for reporting, than in restructuring your 'live' database and having to deal with all the resulting denormalisation issues, etc.
There is a point between transactional and data warehousing that needs to be hit. Simple summaries or considering the question of "how do I retrieve everything in this state" will sometimes suffice. Building a system to get single transactions in an out tends to make routine report take all night or be impossible to get in a reasonable amount of time.
If your schema and app requires non-trivial SQL, then expect maintenance nightmares and lack of ability to scale.
If the problem is complex, you want to model relations, not ignore them.
(But clearly not in this hairy query.)
Denormalization is a performance consideration, and now even happens transparently at the storage layer in some RDBMs. So restructuring a 'live' database should be done for semantic reasons: because the workflow changes; because the app needs to change.
Which of course is much less than the one in the picture, but still very, very bad.
Some so we've refactored the beast. Now it's 2-3 smaller queries (which are much easier to optimize for PostgreSQL and, above all, individually cacheable) which lead to a nearly 100% speedup for common cases. Also, the code is infinitely more readable which means that it's much easier to extend it.
I'm incredibly happy that we've seen the light and fixed it before it grew to proportions like the ones on the original article shudder
-(BASE64?) encoded InstallerIcon,
-(BASE64?) encoded EULAs in various languages
-GUIDs like {01C3BD72-7371-4472-B179-B4DFE6DDD251}
-and my personal favorite: a 25 KB XML fragmentBased on what you're describing, I now believe those developers were poached from Adobe.
I'm looking at a query here that is 37 printed pages, with 92 joins over 25 unions.
I have, however, had the misfortune of troubleshooting those 10 page queries. Finding a stupid typo in one of those is like looking for a needle in a haystack.....
I'd like to say I rewrote it, but I didn't. I just left.
Dens is a great guy, but I hope I never have to rewrite his code again.
And all that for inserting the values taken from the three tables into a 4th table. This could have been done with a simple 3-table join query. Hell, it could even have been done with a single insert statement! I wonder how people fail to recognize an N+1 selects problem when it's staring them in the face.
Well, to be fair, this problem I described isn't exactly an N+1 problem is it? More like an N(M(L+1)+1)+1 selects problem. ;-) (Unless I've got my math all wrong there?)
How I hate working with PL/SQL stored procedures! :(
(disclaimer: I work for mcgn)
Eventually we got the approval to change to MySQL for the database. When they ran the first stock update with the new version they rang us up to check it had worked because it was near instantaneous.
The moral of the story: Access is BAD! VERY BAD!
I can't read much of the query, but at least a few lines are checking for null values. I wouldn't be surprised if 80-90% of the query is simply output formatting. Depending on the DB platform, some formatting and null-check statements are fairly verbose.
That does look like rough going... though in my experience, a nasty-looking mess like that may not be so bad if you simply format it -- with indenting to indicate subquery levels, and maybe some color (like light grey for formatting/null check fluff and bold for SQL keywords).
Often a massive query like that indicates business logic and even display details built into the query -- are there lots of WHEN clauses? Big chunks of the query just managing formatting the output?
If SQL is your "hammer" to fix every problem, you can take a simple query -- say, fetching a user's full name and address from a single table -- and make it really damned long just by cramming everything into the query... is there an address2? A middle name? Did the user capitalize their names (you could fix that in SQL...)? Etc..
I have written some very long SQL before -- a few years ago I flattened many many pages of buggy PHP into a dozen carefully-designed (but a bit complex) materialized views that were the base for the final reporting queries (which could be pretty straightforward; the data involved was already neat & tidy).
If you blew up each view involved and removed all formatting, the reporting queries would be pretty tough to digest; that's the point, though -- all of the complexity was cut up & compartmentalized into well-named bite-sized pieces, so other developers were still able to maintain and extend it after I left.
This query could be condensed considerably if rewritten in htsql.
(htsql automatically generates SQL code that covers all corner cases and executes faster than hand-crafted SQL.)
I once encountered a stored procedure that returned HTML in a result set. It literally created the UI of a webpage. It returned several columns of HTML that the app would place in strategic parts of the page. Well, as years went by, the app required a more innovative and web 2.0 UI. Rather than remove the HTML from the sproc, more columns were returned with more HTML, Javascript and the like. One time I had to fix some Javascript that rendered on the page. When I finally found where the errant JS was coming from, I realized I had to file a database change ticket to fix the UI :)
Things like
select '<table>' from dual; select '<tr><td>'||column1||'</td><td>'||column2||'</td></tr>' from dual;
You can read the email at http://ledger-smb.1045705.n5.nabble.com/Announcing-the-Devel...
Unfortunately people thought I was serious and I still get questions about it. Reading this thread I am starting to understand why....
I might have just been lucky enough to always work at professional companies and startups where this kind of stuff can never happen.
But something tells me there is no reasonable way an SQL query can grow to these proportions.
I'm not old enough to have built systems like that, but I have inherited some for maintenance and debugging. That's not likely to be BS. Back in the day "do it in a stored procedure" was common advice. All the logic for untold applications and millions of lines of code lived at the database level.
Count yourself lucky perhaps to have entered the market when you did, but don't discount that you're standing on tall, sometimes ugly, shoulders.
It was a load of crap, but it still ran about 10x faster than what customers were used to, so they weren't complaining. Last I knew they were still running the same basic setup, and it's been 5 years since I worked there.
Not that I really care about "back in the day!" But it can be helpful to understand why certain things were done in a certain way. It seems like ancient history, but there you definitely will find some old code when you start working at companies that have been around for more than a few years.
But in general, people did thing that way because there wasn't any common middleware or services interfaces. The RDBMS was the "app server".
I've seen other cases, none quite as bad as that one. It tends to be the result of giving a developer who hasn't had any formal training or experience with SQL a requirements doc without any supervision. If all you have ever done is normal imperative coding, you will not even know you are doing it wrong.
You can also find some weird SQL created by report generator tools.
Don't know what to say, other than it's not only possible, it's not all that uncommon. I can't speak to legitimacy of this particular entry, but the absurdity of it doesn't shock me at all.
Spend some time in the marketing or IT divisions of many Fortune 1000 companies, and you'll understand how Daily WTF is therapeutic for those who have to work in those environments.