- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Yes, it can make for ugly code. It nevertheless can be found in a lot of rule books because it has a nice effect on cyclomatic complexity.
Admin
What they meant was
allPreviousElementsWereAlpha
, but anyone with a brain would see whatisChar
means.Admin
UNION doesn't guarantee ordering, but it is likely that the DBMS will sort the intermediate results in order to de-duplicate them. The observed ordering in this case is just a side effect of the implementation, and shouldn't be relied upon (as the specification will probably say that the order of results returned is arbitrary)
Admin
Admin
yeah, sounds like the order of an identity field. tends to appear in order, but no guarantee.
troll bait?
Admin
[quote user=Peteris]The OR solution would have different results in cases where a record matches multiple search criteria - in that case, the current solution would include duplicate rows.[/quote]
No OR and UNION should give the same result. You are thinking of UNION ALL. UNION is the same as "select DISTINCT * from (select UNION ALL select)".
Admin
Admin
Admin
Admin
Admin
Admin
Indeed, union means the individual parts of the query can use indexes, whereas an OR would prevent any index, so it's not actually a bad idea here, :)
Admin
It's an eggcorn. I used to think this was the phrase too... :)
Admin
Bullshit.
There is no way
is more performant than .You simply can't do multiple table scans and beat a single one; aside from the redundant IO, your UNION requires a hash join to toss duplicate rows.
And if MySQL's optimizer is not complete shit, the two should have an identical query plans.
Admin
Thanks! I've spent the last two days redoing all my code to include as many premature assertions as possible :)
Admin
the error seems to be that in your keyboard the 'o' key is malfunctioning
Admin
The union query makes a lot of sense in this situation. It is an optimization over the OR.
Most database engines don't do a very good job with OR, especially if it is the only condition (there are no columns which can be used as the first column in an index to make the data returned more selective), the table has a lot of rows, and the data is very sparse.
The OR will be downgraded into a table scan. If there are millions of records, that means millions of compares, and a lot of disk IO.
In the union query, since the like condition is bounded on the left side (and assuming each of these columns are the first column in at least one index), each sub query will be very selective. The union would then sort and filter out the duplicates (which shouldn't be expensive, as long as the query was very selective).
Admin
This is not an example of the problem in the query listed by the OP. Granted, I feel for the OP's example it is due to a lot of "WTF?", but here the filter is an OR on different columns checking for the same attribute data.. Sometimes these scenarios lend themselves to exlcuding use of an index, depending on the complexity and index setups of course.
Admin
Thank you, very much.................................
Admin
The boolean is used to indicate whether we have found something that invalidates our string from an alpha-only perspective. Assuming you agree NULL/Empty strings are ok, there is little issue startiing in the TRUE state.
I also have no issue with is being used as a loop condition. If it were better named, it adds clarity that we might shortcut the loop.
Of course it might have been better to simply return false rather than play with a var, a'la...:
Admin
Admin
I can imagine with a too-dumb query planner it will not use the indexes in the "OR" version... do you mean to say MySQL is in fact that dumb though?
But the "UNION" version is not in fact equivalent in its result, it will return the same row multiple times if it matches on multiple fields. To fix that he would need to add "DISTINCT" or "GROUP BY", and that may very well kill any performance advantage there was...
Admin
Or, you know, test it.
Admin
Bah, was intended to be a reply to the "you can't know what regexen do" comment, but hit reply instead of quote.
Admin
You're an idiot. If that logic were applied, nobody would ever use library functions, but would write everything themselves. How is that safe, or a good idea? Library functions have, we assume, been checked a lot more thoroughly than your ad-hoc code!
Admin
The EntityTypeDescription should have been 'AE35'
Admin
Mysql before 5.0 had a limitation of 1 index (you are using indexes, right?) per table per query. So if you had an index on (ProjectCode), an index on (ProjectDesc), an index on (TaskCode), and an index on (TaskDesc), doing the query as written would be much faster because it could use each index once, and merge the results together. Otherwise, with the OR clauses, you'd be looking at a single table scan.
e.g. http://www.mysqlperformanceblog.com/2012/12/14/the-optimization-that-often-isnt-index-merge-intersection/