[TYPO3-dev] Default definitions of database fields

[Jigal van Hemert]

Jochen Rau wrote:
> starttime int(11) DEFAULT '0' NOT NULL,
> 
> Why do we use (11) after int, tinyint? As this makes perfect sense for 
> char and varchar, it is IMO useless for int and tinyint because it does 
> NOT indicate how many numbers or bytes the field can hold. It just fills 
> the integer up with zeroes on the left. A 42 stored in an int(11) field 
> is stored as 00000000042. (Don't ask why "42" ;-) )

The number behind an INT only indicates the width that MySQL should use 
to represent the number in the output. Integers are stored as (surprise) 
integers. So 42 is stored as 42 and if it's an INT(11) field, it will be 
'printed' as "         42" (left padded with spaces) or if you define 
ZERO FILL as "00000000042".

If the width is too short for the data that's inside, it might lead to 
problems when MySQL has to make temporary tables for complex queries.

For many other column types the width is also important when comparing 
data in queries. MySQL has to work harder when it has to compare data 
from a VARCHAR(15) field with data from a CHAR(10) field. VARCHAR(15) 
and CHAR(15) is faster.

> Why do we need "DEFAULT '0' NOT NULL"? The starttime set to 0 (unix 
> timestamp) means that we start 1-1-1970 (I know that TYPO3 handles 0 
> different).

Why can't we use a proper date/datetime field? Old dinosaurs also want 
to enter their pre-1970 date of birth :-)
With 2038 approaching rapidly the limits of a UNIX timestamp are also 
going to give problems...

--
Jigal van Hemert.