如何在数据库中组织漫画书位置信息?

时间:2012-06-01 16:48:55

标签: mysql database

我正在制作漫画书数据库项目,我需要能够在特定漫画问题中包含各个位置。我必须处理几个问题:

  • 在其他地方(或每天都有) 军号建筑“在上”第39街和第2大道的角落“是 在“纽约市”是在“纽约”等。)
  • 虽然地点的层次结构非常标准 (宇宙 - > Dimension-> Galaxy->系统 - > Planet-> Continent->国家 - >状态 - >都市>街 - > Building->室), 并非所有父位置都必须为每个位置所知 (漫画可能涉及一个未命名的国家的命名建筑物 例如非洲)。
  • 有一些地方不适合那个漂亮的层次结构但是 在某些时候分支(例如,“野人之地”是一个巨人 在南极洲的丛林,所以虽然它的父母是一个大陆,但它不是一个 国家)。

我的主要目标是能够搜索任何位置并获取具有该位置的所有问题或该位置内的任何位置。第二个目标是能够在应用程序的管理方面能够自动完成完整的位置(即我在一个新建筑物中输入一个问题,并指明它在纽约市,它拉动所有“纽约市” “实例 - 是的,有一个以上:P - 在数据库中让我选择地球-616中的那个或地球中的那个-1610或者我可以在不同的父位置添加新的纽约市) 。我可以做的所有前端工作,并在时机成熟时弄清楚,我现在只是不确定数据库设置。

任何帮助将不胜感激!

更新

在与几个同行进行了大量的头脑风暴之后,我想我已经提出了一个比已建议的嵌套模型更简单的解决方案。

位置表如下所示:

  • ID
  • 名称
  • 类型(前面提到的类别的枚举列表,包括 '其他'选项)
  • Uni_ID(父Universe的ID,如果不适用,则为null)
  • Dim_ID(父Dimension的ID,如果不适用,则为null)
  • Gal_ID(父级Galaxy的ID,如果不适用则为null)

......等等所有类别......

  • Bui_ID(父级建筑物的ID,如果不适用,则为null)

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

2 个答案:

答案 0 :(得分:1)

对于分层数据,我总是更喜欢将嵌套集模型用于parent->子(邻接)模型。查看here以获得良好的解释和示例查询。这是一个更复杂的数据模型,但它使得查询和搜索数据变得更加容易。

答案 1 :(得分: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可能会有点长,但是当你编写简单的查询时,这真的很重要吗?而且由于它只是一个字符串,因此您可以拥有非常大的可扩展性,而无需重新编制索引。