Gonna suggest you study the effects of using enum(0,1) vs int(1).
Also the datelines on MyBB use bigint(30) but int(10) would be preferred. bigint uses twice the bytes as int and dateline is only 10 characters so there is no need for 30.
These save space and resources in the database.
Please consider for 1.8x branch the database structure.
enum is usually better, but only slightly in most cases, especially when comparing to int type data. however it does add some odd requirements whennot used in the 0,1 case you mentioned.
see this article for some details
http://komlenic.com/244/8-reasons-why-my...e-is-evil/
however, the 0,1 case would be better served with a bit(1) field, smaller, faster, lighter, and cross platform.
i do agree that dateline fields are oversized and twice the bytes as needed
Wasn't aware of bit(1) which sounds like a great alternative.
bigint(30) should definitely be changed to int(10) though I'm unaware of the consequences of changing that through an upgrade script - on a large board it may take down your server since it will need to convert every value (though in this case since both are integers I'm not sure of what would happen).
http://stackoverflow.com/questions/42897...nt-columns
Quote:Standard UNIX timestamps are a signed 32bit integer, which in MySQL is a regular "int" column. There's no way you could store 9,999,999,999, as that's way outside the representation range - the highest a 32bit int of any sort can go is 4,294,967,295. The highest a signed 32bit in goes is 2,147,483,647.
If/when UNIX timestamps go to a 64bit data type, then you'll have to use a MySQL "bigint" to store them.
As for int(10), the (10) portion is merely for display purposes. MySQL will still use a full 32bit internally to store the number, but only display 10 whenever you do a select on the table.
would creating a new field of int(10), populate it with the existing data, drop the old field and rename the new field be any better? you can cast the data during the population of the new field and do it in batches. this would stop temporary tables from being needed to store the interim data.
Sounds good to me as long as we don't provide a default value for that field.
you could specify the default during alter to rename it. since they would all be populated, it should have little impact.
Stefan that is a stackflow answer. You might as well accept Yahoo answers too. Sorry but I prefer the MySQL manual.
http://dev.mysql.com/doc/refman/5.0/en/n...types.html
You can see bigint uses 8 bytes to store vs int which uses 4 bytes. Considering how often MyBB tables have dateline columns I think it's an easy way to save some space.
I think the same logic was used for the ipaddresslong that MyBB now uses. FYI that's got a huge bug I wish you guys would fix.
According to MySQL the max unsigned value is 2147483647.
Which is: Monday, January 18, 2038 7:14:07 PM GMT-8
I think 26 years is a generous time and I'm sure if MyBB is still around would be on version 5 and be running some mad crazy scheme which would make this a non issue.
But for now we can save 50% of the space used on all dateline columns by switching from bigint(30) to int(10).