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

【问题标题】：How to organize comic book location information in a database?如何在数据库中组织漫画书位置信息？
【发布时间】：2012-06-05 05:07:32
【问题描述】：

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

位置通常位于其他位置（“每日号角大楼”位于“第 39 街和第 2 大道的拐角处” 在“纽约市”中是在“纽约”等）
虽然位置的层次结构非常标准（宇宙->维度->银河->系统->星球->大陆->国家->国家->城市->街道->建筑->房间），并非每个位置都必须知道所有父位置（漫画可能涉及在一个未命名的国家的命名建筑物例如非洲）。
有一些位置不适合那个漂亮的层次结构，但是在某个时候分支（例如，“野蛮之地”是一个巨人南极洲的丛林，所以虽然它的父母是大陆，但它不是国家）。

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

任何帮助将不胜感激！

更新：

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

位置表如下所示：

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

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

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

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

【问题讨论】：

所以在你的例子中，野蛮土地的唯一父级将是南极洲，而南极洲将在地球之下，依此类推。但即便是蛮荒之地是丛林而不是国家，还是应该在寻找南极的时候归还。
时间值重要吗？例如，世贸中心与世贸中心纪念馆。地点相同，但时间不同。
这将是两个不同的“建筑物”，或者更准确地说，第二个将是与“世贸中心大楼”具有相同父级的那些例外之一（街道，如果它恰好被命名在漫画中）但本身不是建筑物。当一切都说完了，我可能会为相关的位置 ID 添加一个字段来链接类似的东西，但这是简单的部分。

标签： mysql database

【解决方案1】：

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

【讨论】：

这还允许您在必要时更精细或更精细（如 Savage Land 示例）。
那是一篇很棒的文章，谢谢。从我读到的内容来看，我几乎可以比邻接列表模型更干净地实现嵌套集合模型。您对该模型有何看法？
哇...对不起。显然我打字的速度比我想象的要快。嵌套集模型是您想要的模型，邻接列表是父/子模型。我正在编辑我的帖子以反映这一点。
请注意，嵌套集模型是非关系型的——它是基于元数据的。这有其自身的局限性和挑战。如果你打算使用它，看看这篇论文（跳过数学，只关注这个想法，除非你是一个数学专家）：arxiv.org/abs/0806.3115
我还在这里的线程中发布了一些关于嵌套集合模型的想法：llblgen.com/tinyforum/…。请注意，我一般并不反对嵌套集合模型，但它并不总是一个好的选择。

【解决方案2】：

我真的很喜欢@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 可能会有点长，但是当您编写简单的查询时，这真的很重要吗？而且由于它只是一个字符串，因此您可以拥有非常大的可扩展性，而无需重新索引。

【讨论】：