Content Storage - architectural Question

Next topic

Author	Message
Gabriel Ambuehl	Friday 18 April 2003 8:02:20 am 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. Visit http://triligon.org
Paul Borgermans	Saturday 19 April 2003 3:56:24 am 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 eZ Publish, eZ Find, Solr expert consulting and training http://twitter.com/paulborgermans
Paul Borgermans	Saturday 19 April 2003 4:00:22 am >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 eZ Publish, eZ Find, Solr expert consulting and training http://twitter.com/paulborgermans
Gabriel Ambuehl	Saturday 19 April 2003 4:54:48 am 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. Visit http://triligon.org
Sergiy Pushchin	Wednesday 23 April 2003 1: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 :) Chears.
Gabriel Ambuehl	Wednesday 23 April 2003 1: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 :-( Visit http://triligon.org