Zend Framework: Meta attributes (keywords/description) from database

I am creating websites via Zend Framework and I've been wondering about this for quite some time now...

Imagine that you have created the best articles module and you usually add meta_keywords/meta_description database entries per article, so that when the view renders it populates the meta fields in question with the data entered in the administration back-end.

However, imagine the case where you have less dynamic content, and so far you are using the HeadMeta() view helper to add meta keywords/meta description to the page.

I would like to have a way to configure meta keywords/meta description or some other meta elements per page in the database. I've been scratching my head on what is the best solution over this, without adding an excessive overhead (since you would be needing to perform a query for every action that takes place in your website)

My initial thought was to save the meta attributes on a index in the database so that for each action you could quickly retrieve all relevant data. I quickly realized that parameters passed via GET/POST could change the result provided making the result-set irrelevant.

So maybe we could add the parameters as well, but you might want to ignore a few at the same time (since there is no need to take into consideration a ?page=12 parameter...). Maybe adding another varchar column in the index with the serialized parameters?

Or adding the entire URL and perform a REGEXP select instead of a regular select? (I am guessing that t开发者_JS百科his would probably be the slowest solution...)

Also take note that mySQL has a limit on UTF-8 Indexes of about varchar(200) (thus one huge URL could not be saved)

Has anyone thought of a good way of solving this?

It sounds to me like the data structure is right: meta keywords/description need to be per-article.

Ultimately, you need to get articles from the db - whether it is a single article or a group of "best" articles. So seems to me that the key is to keep that maximally performant with some kind of server-side caching.

Typically I use a service class (see sample) that is configured with the db connection and also caches the data it retrieves. Cache lifetime can be set short enough so that even cached-data is "fresh enough". Alternatively, you clear/populate the cache via cron so that front-end requests always get a cache hit. Or you can set the cache lifetime to be forever and only clear/populate the cache on update in the admin side; the viability of this approach depends upon the frequency of update.

After you've got the data, it's jamming the values into the HeadMeta view-helper.