fenway

Yes, you'd be adding the salt back... but the attacker has no idea what the salt is.

I have no idea what you mean. Do you mean blank or null?

Plus, in Mysql 5, you can use CSV directly as a engine type.

I hasn't been re-designed in a very long time... they just don't care.

Google "rainbow attacks" and you'll see why this is important... or use a better hashing algorithm.

Your ORs and ANDs are getting mixed up. $sql = "SELECT * FROM prod_list WHERE ( name LIKE '%$search%' OR short_desc LIKE '%$search%' OR description LIKE '%$search%' ) AND access_levels LIKE '%$user_level%' AND cat_id IN (". implode(',', $items) .") ORDER BY {$orderby} {$ordermeth} LIMIT {$startRange},{$endRange}";

IMESTAMP_CURRENT() isn't a function that I've ever heard of... I think you mean to update the column definition.

Yes, there's a huge difference between disk-bound vs. I/O bound...

Then I don't see any other select statement.

Don't store timestamps in the DB -- use a proper DATETIME field. DATE_FORMAT() will let you return the date how ever you see fit.

Well, as long as the wildcard is at the end, you're ok -- but why the dollar sign?

Well, for your first question, you can either do it client-side (JS) or server-side (say, via AJAX). As for the DB side of things, I'm not sure why you want to "code the URL".

Sorry, you're right I saw less-than and mis-read... I'm not a fan of DATE_ADD(), I prefer CURDATE() + INTERVAL 60 DAY.

What about replication?

How can emb_dob be both before & after today's date? Thats' why the first one's not working. You can use MONTH() and DAYOFMONTH() to extract the non-year part.

Yes. There's always a tradeoff with indexing... I'd rather it read some of the table than do a filesort.

I'm very confused about your db design.

First, if you're only going to be counting the rows, NEVER use SELECT * -- use SELECT COUNT(*)! Second, why not simply do this: SELECT ( SELECT COUNT(*) FROM reviews WHERE visible = 0 ) + ( SELECT COUNT(*) FROM articles WHERE visible = 0 ) AS itemCount

The covering index needs to "cover" (user, x, timestamp) -- no need to worry about asc/desc, mysql can read it in either direction as long as all of the order by fields are going the same way.

yes.

You have an order of operations issue... use parens.

You wouldln't have this problem if you named your PK store_id and directory_link_id -- this also makes it very easy to design FK constraints, JOIN conditions, etc. It's a good convention to adopt.

Not at all... single-pass hashing algorithms are easy cracked -- at the very least use a reasonable salt. Alternatively, use SHA1.

Maybe the "LIMIT 1" is the problem...

Easiest way to the use max(datetime) on the details table with a group by eventID, and then join in this derived table back to the main events table for event-based fields.