views:

80

answers:

4

I'm making a "newest users" page.

All users have an timestamp in the column "unixdate", that it stores when you register. Dont know if this is smart, but I like how effective the UNIX time() is and how simple it is.

Now I am showing the newest users within 24 hours by doing this:

$long = "86400"; // 24 hours in seconds
$query = "SELECT * FROM users WHERE unixdate > time()-$long ORDER BY unixdate DESC";

Is this an good method to show on? And if I would like to show newest within 3 days, would it be * 3?

Thank you

+3  A: 

Your method looks perfectly fine. You might want to select just the fields you want to use, especially if you then access them as a non-associative array. If the database schema changes later, surprises will happen. Also make sure there's an index on the column unixdate of course.

jjrv
Hi, why should there be a index? Whats the index good for? Thank you
Johnson
By index I mean using CREATE INDEX in MySQL or specifying it as a key when creating the table. Otherwise the query will get very slow with more users.
jjrv
@user457827: see e.g. this for intro to indexes: http://www.databasejournal.com/features/mysql/article.php/1382791/Optimizing-MySQL-Queries-and-Indexes.htm
Piskvor
A: 

The only thing i would change is the name/type of the variable.

$seconds_in_day = 86400;
$query = "SELECT * FROM users WHERE unixdate > time()-$seconds_in_day ORDER BY unixdate DESC";

Now when someone reads your code they will know exactly what that variable does. "long" didn't help at all. Also no point in making it a string, make it an integer.

If you were going to have multiple queries i would also change the query variable name. I also prefer sprintf, i think it makes code more readable as well

$seconds_in_day = 86400;
$query_new_members_1day = sprintf( "SELECT * FROM users WHERE unixdate > time()-%d ORDER BY unixdate DESC", $seconds_in_day );
$query_new_members_3days = sprintf( "SELECT * FROM users WHERE unixdate > time()-%d ORDER BY unixdate DESC", $seconds_in_day*3 );
Galen
A: 

It's quite all right. A few minor things:

  • don't use SELECT *, only choose the columns that you want
  • if you see performance problems, you may want to actually pass time()-$long as a constant (for more efficient query - TIME() gets re-evaluated for every row)
  • index on unixdate might be useful
  • UNIX time is undefined beyond the year 2038
  • the query returns the newest users "in the last 24 hours", that could be different from "in the last day" (DST), but if you're aware of this distinction, it's not a big deal.

.

$yesterday = time() - 86400;  
$query = "SELECT somecolumn1,somecolumn2,othercolumn FROM users
                 WHERE unixdate > $yesterday ORDER BY unixdate DESC";
Piskvor
+1 Thanks for the explaining
Johnson
A: 

I also store date in Unix Timestamp format always. I find it a lot easy when working in PHP.

You should use

$long = time() - 86400;

I prefer

$long = time() - 259200;

over 3 * 86400 as it would save a few CPU cycle.

I would also add an index on unixdate field.

Joyce Babu
If you're in a situation where `3*86400` consumes considerably more cycles than `259200`, PHP is definitely the wrong tool for the job, as you're probably making a realtime embedded device ;) In other words, that's a textbook example of a pointless microoptimalization: this difference is completely insignificant in a high-level interpreted language like PHP - you're gaining nothing in speed while making your code less readable.
Piskvor
I make sure my code is well commented $long = time() - 2259200; // 3 * 86400 (3 days) is as readable as $long = time() - 3 * 86400; And if this one time work can save some cycles for free, why not. I am not saying that this will bring a big difference, nor asking to go for these micro optimizations when major bottlenecks are not handled. My style might be different because I develop my own sites and do not work for a client. I do not have to worry about anything. And my code is properly commented for anyone working with me to understand.
Joyce Babu
Parsing and skipping the comment will likely take more time than the multiplication, so you're actually making it both slower and less clear. Optimizing away a single non-critical multiplication in an interpreted language, not to mention outside any loop, is amazingly pointless. If it ever gets compiled to bytecode, the compiler will precompute that multiplication. If you don't use any PHP accelerator which would optimize it for you then it's obviously not speed critical.
jjrv
I am using an opcode cacher, hence there is no problem with parsing the file. Are you saying that the opcode cacher will cache the calculated value of 3 * 86400?
Joyce Babu