动态站点地图、基于多个表的面包屑导航
我有大约 20 个不同的表，每个表都内置了不同的父/子关系。最近，我被要求根据所有这些表格为我们的网站创建面包屑和站点地图。
我的一个想法是从每个表中删除父/子关系，并创建一个基本上包含 id 和parentId 的表，每当我需要拉出父子关系时，我只需将parent_child_relationships 表加入到我想要的任何表中。是专门从那里拉出来的。
这有道理吗？
无论如何，这个想法的问题是我不喜欢它。哈哈。
还有其他人对如何做到这一点有任何其他想法吗？或者基于由 20 个左右的表组成的站点构建面包屑和站点地图的正确方法是什么？
如果有帮助的话，我的网站由 asp.net、ColdFusion 组成，并使用 MSSQL 数据库。
谢谢！
I have about 20 different tables that each have a different parent / child relationship built into them. I've recently been asked to create a breadcrumb and Site Map for our website based off of all of these tables.
One idea I had, was to remove the parent / child relationship from each of these tables and create basically one table that holds the id and parentId and whenever I need to pull the parent child relationship I would just join the parent_child_relationships table to whatever table I was pulling from specifically.
Does this make sense?
Anyway, the problem with this idea is that i don't like it. haha.
Does anyone else have any other ideas of how this could be done? Or what the correct way of building a breadcrumb and sitemap based off of a site comprised of 20 tables or so?
If it helps, my site is comprised of asp.net, ColdFusion and uses a MSSQL database.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不要让 UI 的实现影响模型的设计，尤其是数据库的设计。制作前端原型，让您的客户参与进来，给他们发言权。构建您的面包屑和站点地图，而无需将其最初绑定到您的实际数据库。一旦您的客户说“这就是我们想要的，就像那样”，然后冻结原型，然后进行实际实现 - 您的应用程序将如何请求数据，您将使用什么类型的数据对象，然后构建您的数据库，
“一个我的想法是从每个表中删除父/子关系，并创建一个基本上包含 id 和parentId 的表”
这不是一个非常可扩展的解决方案，不要*反向规范化您的数据库。遵循标准关系数据库建模/规范化技术。许多小的紧凑表和许多关联表。
Do not let the implementation of the UI effect the design of your model and especially not your DB. Prototype the front end, involve your customer(s), give them a voice. Build your breadcrumbs and site map without it initially tied into your actual DB. Once your customer says "thats what we want, just like that", then freeze the prototype, then work on the actual implementation - how will your app request the data, what type of dataobject will you use AND THEN build your db,
"One idea I had, was to remove the parent / child relationship from each of these tables and create basically one table that holds the id and parentId"
This is not a very scalable solution, do not *reverse normalize your db. Follow standard relation database modeling/normalization techniques. Lots of small cohensive tables with lots of association tables.