[Typo3-dev] Future of Typo3 - Aftermath

[Michael Zedeler]

Daniel Brün wrote:

> [cut]
> Here's just the single point of the discussion that I would like to 
> comment on:
> Basically, DB-normalisation is a great thing.
> It makes a huge DB-system very, very modular and smooth.
> 
> BUT: With data spread over many tables, lots of joins are necessary to 
> collect a set of data that actually belongs together, thus definitely 
> impairing performance. Even though normalisation is great in science, in 
> daily use applications it's not always the way to go.

I do not think that the way typo3 uses the database is that bad. The 
rather simple "lets just extend some tables" idea makes it easy to 
create extensions without too much hassle. One colud consider whether 
certain extensions should be rewritten to use separate tables rather 
than just extending existing ones, but the general idea as such isn't 
that bad at all.

When considering the fact that most databases today does not consume 
much space on fields with null values, I think it is a fair trade-off at 
the moment. If this practise were to be changed, a new layer will have 
to be put on top of the database that gives extension developers the 
same ease of use as now, but with a nicer database layout below.

My prime concern so far with regard to database usage is limited to the 
separation of front end vs. back end users and groups. Four tables that 
have been "over-normalized". Thats all.

> My suggestion is to find a decent way between those two paradigms (one 
> huge table against a couple of normalized ones).
> I don't think it makes any sense to completely normalize the system 
> down, but maybe one could split some tables where it makes sense?

Agree. One could ask whether it is a good idea that the 
"newloginbox"-module must extend the tt_content table with 11 fields(!) 
- especially since their values are very likely to be repeated wherever 
they are not null. In practise this will annoy the user too, since 
he/she has to enter the same values every place he or she adds a login 
box. This is an example of something that should be normalized to 4NF.

> In the content-table a couple of rows come into my mind, that could 
> better be placed in some kind of attribute-table containing only 
> key-value pairs. just a thought.

I think that may easilly lead to many people resorting to such place for 
data storage when it is very far from optimal.

Regards,

Michael.