For large amount of data (Esp when used for sorting) avoid using parameters, put all data needed for sorting serialized to, for example, article->abstract (which is returned by mgd_list_topic_articles() [or $topic->extra in case of topics]), reading the data into arrays and juggling there is not computationally too expensive (it's mostly memory intensive, if there is huge amounts of data), of course this is a tradeoff, you trade some efficiency for midgards ready built DB abstractions (and of course the replication).... I'm wondering how you filter or sort on price when you store the price field as a article/topic parameter? Or perform a bulk update (such as "convert the prices to Euro"). Load the entire car list in an array and then sort/filter/update-one-by-one? What then if you get thousands of articles? (it may not be here the case, so if it's only some tens of cars, storing it in Midgard might be a good solution indeed) It just seemed more easy to me to create a separate table for it, so you can use simple sql statements to perform these typical db tasks.
This way there is no need to rely on external files or databases and install/upgrade can be done using single repligard package.
So far I have not come across anything that would absolutely require separate DB structure for efficiency reasons and I have opted doing everything by extending midgard, due to simpler replication.Again, it 'll depend on Andrey's requirements what will be the right solution for him. I just wanted to make the point that I for myself try to use Midgard for the content management and templating aspects of a web app, whereas for data processing I find it more easy to create a separate data structure and use other existing frameworks in plain php.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
