在 cms 中哪里存储完整的 url？
我正在创建一个 cms，但尚未决定在结构中的何处存储给定页面的完整 url。
每个页面都有一个 slug（页面的 url 友好名称），并且每个页面都有一个可以为 null 的（对于顶级页面）父级和子级。
在哪里存储给定页面的完整 url (/first-page/sub-page)？ 它应该与页面的其他属性一起放入数据库中还是某个缓存中？
更新
我问的不是数据库设计，而是在哪里存储给定页面的完整 url，因此我不需要遍历整个 url 来获取用户请求的页面（ /first-page/sub-page)
更新 2
我需要找到哪个页面属于当前请求的 URL。 如果请求的 url 是 /first-page/sub-page 我不想拆分 url 并循环访问数据库（显然）。
我宁愿在表中包含整个 url，这样我就可以执行单个查询（WHERE url = '/first-page/sub-page'），但这似乎并不理想，如果我更改父页面？ 然后我还需要更新所有后代的 url 字段。
其他人如何解决这个问题？ 他们是否将其放入数据库中？ 在将 /first-page-/sub-page 映射到页面 id 的缓存中？ 或者他们是否分割请求的 url 并循环访问数据库？
谢谢
安德斯
I'm creating a cms and have not yet settled on the matter of where to store the complete url for a given page in the structure.
Every page have a slug (url friendly name of the page) and every page has a nullable (for top-level pages) parent and children.
Where do I store the complete url (/first-page/sub-page) for a given page? Should this go in the database along with the other properties of the page or in some cache?
Update
It's not the database design I'm asking about, rather where to store the complete url to a given page so I don't need to traverse the entire url to get the page that the user requested (/first-page/sub-page)
Update 2
I need to find which page belongs to the currently requested url. If the requested url is /first-page/sub-page I don't want to split the url and looping through the database (obviously).
I'd rather have the entire url in the table so that I can just do a single query (WHERE url = '/first-page/sub-page') but this does not seem ideal, what if I change the slug for the parent page? Then I also need to update the url-field for all descendants.
How do other people solve this issue? Are they putting it in the database? In a cache that maps /first-page-/sub-page to the id for the page? Or are they splitting the requested url and looping though the database?
Thanks
Anders
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
将其存储在缓存中，因为 Web 服务器需要不断查找 URL。 除非您期望页面的 URL 变化非常快，否则缓存将大大减少数据库的负载，这通常是数据库驱动的网站的瓶颈。
基本上，您需要一个映射 URL 的字典 -> 渲染页面所需的任何内容。 许多网络服务器会自动使用操作系统的文件系统作为字典，并且通常具有内置缓存，可以识别文件系统中的文件何时发生更改。 这可能比您在 CMS 中编写的任何内容都要高效得多。 因此，让 CMS 直接在文件系统中实现该结构并使用硬链接或软链接处理附加映射可能会更好。
Store it in a cache, because the web servers will need to be looking up URLs constantly. Unless you expect the URLs of pages to change very rapidly, caching will greatly reduce load on the database, which is usually your bottleneck in database driven web sites.
Basically, you want a dictionary that maps URL -> whatever you need to render the page. Many web servers will automatically use the operating system's file system as the dictionary and will often have a built-in cache that can recognize when a file changes in the file system. This would probably be much more efficient than anything you can write in your CMS. It might be better, therefore, to have you CMS implement the structure directly in the file system and handle additional mapping with hard or soft links.
我只是为 MvcCms 执行此操作。 我采用了内容类别/子类别和内容页面的想法。 创建内容类别/子类别时，我会递归地遍历父类别并构建整个路线，然后将其存储在类别表中。 然后，当请求页面时，我可以找到正确的内容页面，并在浏览导航结构时找出当前正在构建的导航是否是当前或活动路线。
此方法需要一些关于编辑类别时发生的情况的规则。 现在的方法是，一旦为子类别设置了完整路径，以后就无法使用普通工具进行更改。
来源是 mvccms.codeplex.com
I just did this for MvcCms. I went with the idea of content categories/sub categories and content pages. When a content category / subcategory is created I go recursively through the parents and build the entire route and then store it in the category table. Then when the page is requested I can find the correct content page and find out when going through a nav structure if the current nav being built is the current or active route.
This approach requires some rules about what happens when a category is edited. The approach right now is that once the full path is set for a sub category it can't be change later with the normal tools.
The source is a mvccms.codeplex.com