下面是用例：
1.我想建立一个数据库，存储大量项目之间的关系。
1.我的方法是有两种类型：节点（字符串）和集合（其包含任何数量的节点或其他集合或两者），这允许几乎无限的描述性和细微差别。
1.我想通过查询任何项目的主键，可以看到它如何融入整体，即它包含什么以及其他集合包含它。
1.因此，我考虑使用一个四列表：a.键B.人类可读的名称c.内容（在节点的情况下为一个字符串，或者在集合的情况下为所包含的项的一组键）d.包含者（包含该项的集合的键的列表）
然而，仔细阅读，似乎列表不是一种原始的数据类型，而且，SQL中似乎有一个规范，即不应该在单个单元格中存储多个值。
我很想听听你的想法，1.是否有一种不同的方式来思考我的问题，这样我就可以保持一个查找标准来回答一个给定的项目如何适应系统的问题，而不是在一个单元格中有多个值，2.如果这个规范不适用于我的情况，一些漂亮的方法来解决这个问题，例如，分隔字符串（我对此保持沉默，因为这意味着要做更多的数据处理）。
1条答案
按热度按时间lawou6xi1#
看起来你想自己用一个自定义的编码来编码n-m关系。那似乎适得其反。SQL数据库是显式地用来表示对象关系的。一个n-m关系通常是用一个单独的链表来表示的。如果你的实体都是相同的类型，比如说一个类型“node”，然后在node表中放入一个id（主键）列和任何内容（人类可读的名称），你想关联到节点的其他列。一个单独的'边缘'表有链接：例如，如果你的链接被定向，则它可以具有列“源”和“目标”，其中两者都引用节点的ID。
但请注意：你所描述的听起来像一个图形，所以也许图形数据库更适合你的目标。
请注意，使用SQL在互联网上搜索n-m关系应该会为您提供相当多的额外见解，因为这将是非常标准的问题之一。