NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Larry Wall in perl.c from the perl source code
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Database Rule #2 (Score:2)
This might inspire similar levels of disagreement.
If a query is expected to return one row, then it had better be specify the key in the WHERE clause. Never depend on some other considerations to result in only one row being returned. Uniquely constrained fields might be used instead.
Corollary: any time you have a query which returns only one record, encapsulate it in a function. That might be a PL/SQL function or a Perl function or something else.
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Optimization (Score:2)
With Oracle (and others?), a sort operation is guaranteed to increase CPU usage and can significantly affect query performance. In addition, there can be extra I/O overhead, which can cause you to slam into your I/O limits, especially if a disk sort is required. Plus, all rows must be accessed and sorted before the first
Re:Optimization (Score:2)
You've mentioned great examples of where optimization should still be done after the fact. If I don't know that a query (and I frequently create huge queries) is going to cause a problem with performance, I am not going to worry about it up front. The simplest thing to do is simply to have the SQL specify the order. That's what SQL is there for, after all. If some DBA tells me "I don't want you using SQL the way it's intended to be used," I would suggest that the DBA is sorely mistaken -- if that's a bl
Re:Optimization (Score:1)
It's common sense, if an index is being used and there's no ORDER BY clause, then rows will be returned in the order of the index. But I wouldn't generally rely on it in production application code and I would explicitly specify the ORDER BY if that's the order I wanted.
I have run across production code that had somet
Still not convinced :-) (Score:1)
The efficiency argument doesn't persuade me.
If you need ordering for the production code then it's needed by the problem domain and it obviously makes sense.
If ordering is not needed by the production code and just makes the test more convenient to write then it smells to me. You're unnecessarily exposing implementation details to the test suite.
You're also swapping slower tests for slower pro
Re:Still not convinced :-) (Score:2)
I think I should have been clearer about the "apply logic as early as possible" rule. I'm not advovating applying unecessary logic. I'm advocating applying the logic as early as is reasonable. If you need your database records sorted, sort them in the database, if possible. This discussion, to be quite frank, came from me working on some code which returns records in database order and is sorted after it's fetched, but this led to places in the code where it should have been sorted, but wasn't. I was v
Re:Still not convinced :-) (Score:1)
You don't care in which order you pull the Scrabble tiles out of the bag, only that it contains nothing more or less than a complete set.
Re:Still not convinced :-) (Score:1)
What chromatic said :-) Things like eq_set from Test::More or cmp_set and cmp_bag from Test::Deep.