Don't worry about the database structure and performance too much: its only a very minor part of the processing (as opposed to the 2.2.x series < 2.2.8) . The ezp 3.0 database is heavily normalised as far as i can tell and according to schoolbooks, one should always do so. It also leads to the flexibility with content classes without altering table structures on the fly.
Most of the time (up to 80%) is spent processing templates. This area will be improved as you can read elsewhere.
>Another field containing a readily assembled XML
>representation of the row would be great for caching, I >suppose.
This is a matter for caching actually. I guess it all boils down to a sound database structure (not that it is subject to improvements), where the performance issues are mainly addressed by the various cache levels. As mysql 4 has query caching, this will increase speed too.
I have mixed views on normalization. The theory not to have any data more than one time is sound but in practive normalizing all the tables will very often give you bad performance as you need to do way too many queries.
When I develop databases, I normally don't care for textbook advice and instead will often have data more than one time grouped together to allow very few queries to retrieve as most apps will have orders of magnitude more accesses compared to writes which obviously get more expensive when you need to update several rows at once. In a way, normalization is opposed to caching data like you read it. In many of my apps there will be ten times more data that's simply there readily assembled for caching purposes than unique data.
I just thought it would make it much easier for other modules to use content's really nice rendering infrastructure if content could read other tables as well as they could fill/pull data from the data without going thru the complete API.
I wanted to implement a calendar for one. That would be easier to implement with one row per event instead of having a calender container group and a lot of calendar event instances.
When you fetch children of node with all their attributes, if all classes have separate tables we will need for each child object send query to database. But now we can fetch objects in one query. (Actualy not one but still less then for each one). It is one smallest point.
--SP
P.S. School books are not that bad as you think :) Chears.
