2

我正在从事漫画书数据库项目，我需要能够在特定漫画问题中包含各个位置。我必须解决几个问题：

  • 地点通常位于其他地点内（“号角日报大楼”在“第 39 街和第二大道的拐角处”在“纽约市”在“纽约”等）
  • 虽然位置的层次结构非常标准（Universe->Dimension->Galaxy->System->Planet->Continent->Country->State->City->Street->Building->Room），但并非所有父位置每个位置都必须知道（例如，漫画可能涉及非洲某个未命名国家的命名建筑物）。
  • 有一些地方不适合那种漂亮的等级制度，但在某些时候会分支（例如，“野蛮之地”是南极洲的一个巨大丛林，所以虽然它的父级是一个大陆，但它不是一个国家） .

我的主要目标是能够搜索任何位置并获取具有该位置或该位置内任何位置的所有问题。第二个目标是能够在应用程序的管理方面能够自动完成完整的位置（即，我为一个问题键入一个新建筑物并指定它在纽约市，它会拉出所有“纽约市“实例——是的，数据库中不止一个:P——让我选择Earth-616中的一个或Earth-1610中的一个，或者我可以在不同的父位置下添加一个新的纽约市） . 我能做的所有前端工作，并在时机成熟时弄清楚，我只是不确定此时的数据库设置。

任何帮助，将不胜感激！

更新：

在与几个同行进行了多次头脑风暴之后，我想我想出了一个比建议的嵌套模型更简单的解决方案。

位置表如下所示：

  • ID
  • 姓名
  • 类型（前面提到的类别的枚举列表，包括“其他”选项）
  • Uni_ID（父 Universe 的 ID，如果不适用，则为 null）
  • Dim_ID（父维度的 ID，如果不适用，则为空）
  • Gal_ID（父 Galaxy 的 ID，如果不适用，则为 null）

...等等通过所有类别...

  • Bui_ID（父建筑物的ID，如果不适用则为空）

因此，虽然有很多字段，但搜索和自动完成工作真的很容易。任何给定位置的所有父级都在行中，任何位置的所有子级都可以通过单个查询找到，并且一旦为新位置定义了类型，自动完成就可以轻松工作。在这一点上，我倾向于这种方法而不是嵌套模型，除非有人能指出我没有看到的这种设置的任何问题。

4

2 回答 2

1

对于分层数据，我总是更喜欢使用嵌套集模型而不是父->子（邻接）模型。在这里寻找一个很好的解释和示例查询。这是一个更复杂的数据模型，但它使查询和搜索数据变得更加容易。

于 2012-06-01T17:08:10.380 回答
0

我真的很喜欢@King Isaac 之前关于嵌套集合模型的链接。我对链接所说的唯一论点是可扩展性。如果你定义你的 lft 和 rgt 边界，你必须知道你有多少元素，或者你必须设置任意大的数字，只是希望你永远不会达到它。我不知道这个数据库会有多大以及您将拥有多少条目，但最好实现一个不需要重新索引等的模型。这是我的修改版本

create table #locations (id varchar(100),
                         name varchar(300),
                         descriptn varchar(500),
                         depthLevelId int)

create table #depthLevel(id int,
                         levelName varchar(300))

                     ***Id level structuring*** 

                            10--level 1
              100                               101-- level 2           
     1000            1001               1010             1011       --level 3
 10000   10001   10010   10011     10100    10101    10110    10111     --level 4

从本质上讲，这使得查询变得超级简单。重要的部分是子 id 由父 id 加上你想给它的任何随机 id 组成。它甚至不必是连续的，只要是唯一的。你想要宇宙中的一切吗？ 

SELECT * 
FROM #locations
WHERE id like '10%'

你想要第四层以下的东西吗？ 

SELECT * 
FROM #locations 
WHERE id like '10000%'

当您下降这么多级别时，id 可能会有点长，但是当您编写简单的查询时，这真的很重要吗？而且由于它只是一个字符串，因此您可以拥有非常大的可扩展性，而无需重新索引。

于 2012-06-01T22:13:57.890 回答