Re: PHP and MySQL queries...
| From: | Steve Cayford | Date: | Thu, 25 Oct 2001 15:06:52 +0000 |
| Subject: | Re: PHP and MySQL queries... | ||
| References: | 1 | Groups: | php.db |
| Request: | Send a blank email to php-db+get-13716@lists.php.net to get a copy of this message | ||
Oop. I guess I missed the point of that question. Still, the MySQL manual says a DATE takes 3 bytes, DATETIME 8 bytes, and TIMESTAMP 4 bytes. That seems fairly efficient. Using an INT for a date might actually take up more space.
-Steve
On Thursday, October 25, 2001, at 09:34 AM, Steve Cayford wrote:
Yep, MySQL has DATE, DATETIME, and TIMESTAMP field types. You can order by them and everything. -Steve On Thursday, October 25, 2001, at 09:18 AM, Tim Foster wrote:I'm new to this list, to PHP and to MySQL (been doing VBScript on ASP for several years, tho). I'm curious... If you're going to store it as an integer, why not store "10/24/2001" as YYYYMMDD (20011024). This gives you the added benefit of being able to have the db sort your fields. This even works if you want to include the time with your date (provided all dates in the field consistently contain the same *amount* of info). For example, noon on Christmas will always be lower than noon of the following New Year ..as it should be: YYYY/MM/DD 20011225 < 20020101 YYYY/MM/DD HH:MM 200112251200 < 200201011200 YYYY/MM/DD HH:MM:SS 20011225120000 < 20020101120000 I'm betting there's no easy way to sort it if you store it as MM/DD/YY MM/DD/YYYY 10242001 < 12252001 (good) ..but NOT less than the following New Year's MM/DD/YYYY 10242001 > 01012002 (bad) Granted, you might take up a bit more space in the DB, which would have a tiny impact on performance(??), but an extra $100 on the hard drive would effectively eliminate any reasonable space considerations and (IMHO) reduce the amount of programming/debugging to more than justify the overhead. FWIW, M$ likes to store their dates as two integers: one to hold the date portion, the other to hold the hours:minutes:seconds portion. If there's something about PHP/MySQL that makes this point moot, please let me know. TIM -He who always plows a straight furrow is in a rut.-- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: php-db-unsubscribe@lists.php.net For additional commands, e-mail: php-db-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net-----Original Message----- From: Mike Frazer [mailto:mike@invertedmind.com] Sent: Wednesday, October 24, 2001 7:54 AM To: php-dev@lists.php.net; php-db@lists.php.net Subject: Re: [PHP-DB] PHP and MySQL queries... Agreed. This is especially useful when you need to conserve every byte you can; a timestamp of "10/24/2001" or something similar is going to take 10 bytes as a string and an indeterminate number of bytes for an actual timestamp because of system variations, whereas an integer value of 10242001 will take you 2-4 bytes depending on the type of int you declare. Not a lot of space, but assume for a second you have 30 fields in your database and 5 million rows...suddenly those 6-8 bytes have multiplied on this one field alone. Space and speed are important in DBs :) Mike Frazer-- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: php-db-unsubscribe@lists.php.net For additional commands, e-mail: php-db-help@lists.php.net To contact the list administrators, e-mail: php-list- admin@lists.php.net