Size of Date/Time fields in DB

[antiroot]

I noticed today that everywhere that references date/time MaNGOS is using a unix timestamp and storing that in the DB as a bigint(11). This makes sense for 64bit systems that actually use a 64bit time_t, but on 32bit systems generally a 32bit time_t is defined in the standard C lib.

So with that said, for all of us users running a 32bit OS we are wasting 4bytes for every timestamp in the DB

Example: Table `character_achievement_progress` has 5925 records (in my DB ), that's 23700 bytes wasted because the timestamp is being stored as bigint, and there are many tables that store timestamps like this

Would it be logical to switch the timestamps to something platform independent like using MySQLs DATETIME storagetype, I know thats still 8 bytes but at least we're not wasting any that way.

This is not a database request at all, and I also know that changing from a timestamp to a different format would require extensive changes to all the source code that uses these timestamps, I'm only curious to know what others think

Side Note: Yes I know all of us 32bit people are going to need to make a switch to 64bit before the Y2K38 bug rolls around

[DasBlub]

when i implemented the no_char_delete patch, i first used a DATETIME field from MySQL. i later changed it to BIGINT(11) due to the fact, that PGSQL and MySQL don't have the same datatypes and functions for it. it was impossible to implement the checks i needed to do, because i couldn't use any DB-internal functions.

and HDDs are very cheap nowadays, you can get 2TB as RAID-edition (= 24/7 HDDs) for something around 300$ and normal hdd's are even cheaper.

-- DasBlub

[antiroot]

Oh yes, I forgot about PgSQL being a supported database. My concern was not for wasted disk space, but for the wasted resources that would have to deal with the excess data that wouldn't even be used.

Thanks for the reply, a simple explanation was exactly what is was looking for and choosing to support both MySQL/PgSQL makes perfect sense why we would have to use datatypes that aren't the proper type for one DB, but the only type for another