This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit ezplatform.com

eZ Community » Forums » Developer » Content Storage - architectural Question
expandshrink

Content Storage - architectural Question

Content Storage - architectural Question

Friday 18 April 2003 5:02:20 pm - 5 replies

I've been looking at the implementation of the content module and the whole attribute stuff strikes me as being kinda inefficient by cramming everything into the same table.

Why doesn't content just create a new table for each class with fields for each of the attributes? (And a meta table to describe field much like it is now). Another field containing a readily assembled XML representation of the row would be great for caching, I suppose.

Seems to me that would be a much more efficient way to store the data AND it would make it much much easier for modules to operate on the data. It could pose a few problems for searching though (mostly because you need to search through all tables instead of one).

I mean don't get me wrong, I love the functionality of the content module, it just runs too slow. Most of the design is really elegant and easily the best open source CMS code I've ever looked on but this strikes me as rather weird. Maybe there are reasons to this I don't get so please enlighten me.

Saturday 19 April 2003 12:56:24 pm

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.

Paul

Saturday 19 April 2003 1:00:22 pm

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

Paul

Saturday 19 April 2003 1:54:48 pm

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.

Wednesday 23 April 2003 10:01:42 am

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 happy.gif Emoticon
Chears.

Wednesday 23 April 2003 10:32:27 am

Your professors must have been better at chosing them than mine then. One of the reasons why I switched away from CS major sad.gif Emoticon

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from