There are a few things that I can think of to do, that wouldn't involve much SQL.

The SQL Way:

• Make sure you CREATE INDEX mycleverindexname on mybadasstable (myslickcolumn) This will speed you up a ton, and the space tradeoff is almost always worth it if you're going to be doing a lot of sorting on it.
• Re-ordering them really isn't scalable. That cron job is going to sting if your site gets above X number of users.

Or you can do it the perl way

• I'd suggest keeping a preferences table with a column for this arrangement, such something from a Data::Dumper dump of an array of primary key entries, or even something easily parsed, such as a comma delineated string of Primary Key entries. This "caching" of sorts is very useful, and quite scalable, since you only have to update one record when you need to change it. Plus rearranging it you can do very quickly in perl, rather than having some sort of kludgy re-order logic in SQL.
  
  Basically, keep a string of "34,48,29,32,15" where each one corresponds to your "nodelet" like item, then sort it, rearrange it, hash it, or serve it with a side of cole slaw. Whatever you'd like.

    my @array = split("," $sql_result);
  [download]

Typically, I'd like to think that perl is better for sorting small to moderate result sets. For instance instead of doing a huge "select" with a parameter, and then sorting by a certain value, then doing the "order by" statement when you know that you're only going to get a few results, bite the bullet, get out of your sql (and whatever locks it might have) and do it quickly in perl.

Hope this helps.     --jay