is there such thing as a query being too big?

I don't have too much experience with SQL. Most of the queries I have written have been very small. Whenever I see a very large query, I always kinda assume it needs to be optimized. But is this true? or is there situations where really large queries are just whats needed?

BTW when I say large queries I mean 开发者_如何学Pythonqueries that exceed 1000+ chars

Yes, any statement, method, or even query can be "too big".

The problem, is actually defining what too big really is.

If you can't sit down and figure out what the query does in a relatively short amount of time, it's probably best to break it up into smaller chunks.

I always like to look at things from a maintenance standpoint. If the query is hard to understand now, what if you have to debug something in it?

Just because you see a large query, doesn't mean it needs to be changed or optimized, but if it's too complicated for its own good, then you might want to consider refactoring.

Just as in other languages, you can't determine the efficiency of a query based on a character count. Also, 1000 characters isn't what I could call "large", especially when you use good table/column names, aliases that make sense, etc.

If you're not comfortable enough with SQL to be able to "eye ball" the design merits of particular query, run it through a profiler and examine the execution plan. That'll give you a good idea of problems, if any, the code in question will suffer from.

My rule of thumb is this: write the best, tightest, simplest code you can, and optimize where needed - ie, where you see a performance bottleneck or where (as frequently happens) you slap yourself in the head and say "D'OH!" at about three in the morning on vacation.

Summary:Code well, and optimize where needed.

As Robert said, if you can't easily tell what the query is doing, it probably needs to be simplified.

If you are used to writing simple stuff, you may not realize how complex getting information for a complex report might be. Yes, queries can get long and complicated and still perform well for what they are being asked to do. Often the techniques that are used to performance tune something may make the code look more complicated to those less familar with advanced querying techniques. What counts is how long it takes to execute and whether it returns the correct data, not how many characters it has.

When I see a complex query, my first thought is does it return what the developer really intended to return (you'd be surprised at how often the answer to that is no) and then I look to see if it could be performance tuned. Yes there are many badly written long queries out there, but there are also as many or more that do what they are intended to do about as fast as it can be done without a major database redesign or faster hardware.

I'd suggest that it's not the characters that should measure the size/complexity of the query.

I'd boil it down to:

• what's the goal of the query?
• does it used set-based logic?
• does it re-use any components?
• does it JOIN improperly/poorly?
• what are the performance implications?
• maintainability concerns - is it written so that another developer can grok its intentions?

Where I work we've created stored procedures that exceed 1000 characters. I can't really say it was NECESSARY but sometimes haste wins out over efficiency (most notably when a quick fix is necessary for a client).

Having said that ... if given the time I would attempt to optimize a query as small/efficient as it can get without it being overly confusing. I've used nested stored procedures to make things a little more clear and/or functions as well.

The number of characters does not mean that a query needs to be optimized - it is what you see within those characters that does.

Things like subqueries on top of subqueries is something I would review. I'd review JOINs as well, but it shouldn't take long comparing to the ERD to know if there's an unnecessary JOIN - the first thing I'd look at would be what tables are joined but not used in the output, which is fine if the tables are link/corrollary/etc tables.