I believe that writing scalable applications that rely on this technique to run the equivalent of complex SQL queries is... between impossible and not worth it. But maybe my view is skewed by the types of projects I work on, which tend to imply several million hits per month on complex SQL queries, over a tens of thousands of records. We focus a lot on optimizing our queries, caching and pre-processing as much as possible.
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()
This way there is no need to rely on external files or databases and install/upgrade can be done using single repligard package.A simple makefile, or a couple of scripts are an alternative. You can't package everything in repligard (although Andrey proposed an interesting alternative that might mean you can), but you can always package it somehow. I am not a purist ;)
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.What are the -- presumably important -- benefits of replication that prompt you to add significant complexity and limit the scalability of your application, just to avoid using a simple makefile or shell script?
I don't want to start a flamewar. It is a matter of trade-offs, and a subtle one at that, so I am ok with anything you choose to do. I would like to understand the reasoning behind it. There is always the strong chance I am missing a few clues, and it might be a good practice to contemplate for my own projects.
regards,
m
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
