Zend Framework：数据库中的元属性（关键字/描述）
我正在通过 Zend Framework 创建网站，我已经想知道这个问题有一段时间了...
想象一下，您已经创建了最好的文章模块，并且通常为每篇文章添加 meta_keywords/meta_description 数据库条目，以便在视图呈现时它使用在管理后端输入的数据填充相关元字段。
但是，想象一下这样的情况：您的动态内容较少，并且到目前为止您正在使用 HeadMeta() 视图助手向页面添加元关键字/元描述。
我想要一种方法来配置数据库中每页的元关键字/元描述或一些其他元元素。我一直在绞尽脑汁地思考什么是最好的解决方案，而不增加过多的开销（因为您需要对网站中发生的每个操作执行查询）
我最初的想法是保存元属性数据库中的索引，以便对于每个操作，您都可以快速检索所有相关数据。我很快意识到通过 GET/POST 传递的参数可能会更改提供的结果，从而使结果集变得无关紧要。
因此，也许我们也可以添加参数，但您可能想同时忽略一些参数（因为不需要考虑 ?page=12 参数...）。也许使用序列化参数在索引中添加另一个 varchar 列？
或者添加整个 URL 并执行 REGEXP 选择而不是常规选择？ （我猜这可能是最慢的解决方案...）
还要注意 mySQL 对 UTF-8 索引的限制约为 varchar(200) （因此无法保存一个巨大的 URL）
有没有人想到过解决这个问题的好方法？
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 this 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在我看来，数据结构是正确的：元关键字/描述需要针对每篇文章。
最终，您需要从数据库获取文章 - 无论是单篇文章还是一组“最佳”文章。因此，在我看来，关键是通过某种服务器端缓存来保持最高性能。
通常我使用服务类（查看示例），它配置了数据库连接，并且还缓存它检索的数据。缓存生命周期可以设置得足够短，以便缓存数据也“足够新鲜”。或者，您可以通过 cron 清除/填充缓存，以便前端请求始终获得缓存命中。或者您可以将缓存生命周期设置为永久，并且仅在管理端更新时清除/填充缓存；这种方法的可行性取决于更新的频率。
获得数据后，它会将值塞入 HeadMeta 视图帮助器中。
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.