fenway

I can't guess what that query is going to do.

That's very complex -- you'd have to break up each period into days, and then compare each hour against "valid" hours.

Depends how 'remote' it is.

In general, you can use TIMEDIFF() and then TIME_TO_SEC(). But if you want further restrictions, you'll need to break up each datetime into business and non-business parts first.

This topic has been moved to Application Design. http://www.phpfreaks.com/forums/index.php?topic=350577.0

I didn't realize that was the the primary index -- are you really returning that many rows?

For update, it's often required -- but without seeing the statements, I can't be certain.

You're missing an index on the "s" table.

If the spaces are simply delimiters, then you can hack it -- replace() spaces with commas, then use FIND_IN_SET(). But you really should fix your table.

I have no idea what you're talking about. Echo the actual queries, and we'll see if anyone can help.

utf8_general_ci is pretty "general".

Everyone wants help -- but it's a free forum -- don't report-- that's against the rules.

It's always better to start off normalized.

AND where's the "IS NULL" part from the original link I gave you?

Using one table is just plain lazy.

Sorry, I don't follow...?

Store as many decimal places as you actually need -- then they aren't "extra".

You may have none that you like, but you defintely have something.

Then you created them incorrectly. But that wasn't your problem -- your problem was that you think that you're getting duplicates.

It's always easy to make things "more normalized" later.

I don't believe you that you're getting duplicates in any table with a UNIQUE key. And if "something" gave you that create table structure, it's wong.

Then try "a.date < b.date" instead.

Yeah, it's not pretty -- but there is little you can do if you want all the results co-dependent.

What's "it"?

You'll have to consult the mysql refman for syntax -- I assume that's where you got "MATCH..AGAINST" from.