[TYPO3-dev] Default definitions of database fields

[Jochen Rau]

Hi Jigal

On 11.02.10 23:48, Jigal van Hemert wrote:
> 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.

Thanks for clarification. I have posted my last message before I read 
your comprehensive one ;-)

>> 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...

Yes. That’s true.

But one question remains (besides the date problem): Why does TYPO3 
forces us to use NOT NULL on every field definition?

Jochen