复杂数据建模的设计模式

Question

我正在开发一个以SQL数据库作为后备存储的程序。作为一个非常广泛的描述，程序本身允许用户在任意数量的用户定义的表中生成记录并在它们之间建立连接。至于规格：

1. 生成的任何记录必须能够连接到任何其他用户表中的任何其他记录(不包括itself...the记录，而不是表)。是的，这会创建任意用户生成的关系映射。
2. 这些“连接”是定向的:传入、传出和双向。
3. 记录的连接列表是用户排序的。
4. 记录必须“知道”从它与其他人建立的联系以及从其他人与它的联系。
5. 一个记录的字段还可以包含来自它的连接的聚合信息(比如获取平均值、和等)，这些信息必须在与其连接的另一个记录的变化中更新。
6. 为了节省内存，必须在任何时候只加载相关信息(不能在加载时将整个数据库加载到内存中并从那里加载)。
7. 我不能假设后备商店是本地的。现在是这样，但最终这个程序将包括对远程db的同步。
8. 我不能依赖于备份存储的特定实现。这意味着我不能确定后台存储实际上是关系存储。因此，所有关系数据都显式存储。

连接是这个程序的一点，所以很有可能连接的数量很高，特别是当用户按预期使用软件的时候。在设计时，用户表、连接或记录都不是用户生成的。

我花了很多时间试图找出如何设计备份存储和对象模型，以最适合这些规格。在我的第一次设计尝试中，我有一个对象管理一个表的所有记录和连接。我之所以尝试这样做，首先是因为它使内存占用更小(记录和连接是简单的dicts)，但是维护表became....onerous之间的聚合和链接信息(即.一个巨大的意大利面混乱)。使用此方法跟踪依赖关系几乎变得不可能。相反，我已经确定了一个分布式智能图，通过管理它自己的数据和与其他记录的连接，每个记录和连接都“知道”它周围的是什么。这样做增加了我的内存占用，但也允许我创建一个故障系统，以便连接/记录在需要之前不会加载到内存中。编写代码也容易得多:跟踪依赖关系、消除循环递归更新等等。我最大的问题是存储/加载连接。我对我目前的任何解决方案/想法都不满意，所以我想问一问是否还有其他人对如何构建这个问题有任何想法。连接相当简单。它们包含: fromRecordID，fromTableID，fromRecordOrder，toRecordID，toTableID，toRecordOrder。到目前为止，我想出的是：

1. 把所有的连接存储在一张大桌子上。如果这样做，要么一次加载所有连接(一个大的db调用)，要么每次加载用户表时进行调用。这里的大问题是: connections表的大小可能会很大，我担心它会减慢速度。
2. 将每个用户表的所有传出连接存储在单独的表中。这可能是我想过的最糟糕的主意了。现在，我的连接被“分散”在多个表上(每个用户表一个)，这意味着我必须加载每个表来查找特定用户表的所有传入连接。我避免了制作“一张大屁股桌子”，但我不确定这个成本是否值得。
3. 将每个用户表的所有传出和传入连接存储在单独的表中(使用一个标志来区分传入的还是传出的)。这是我倾向于的想法，但实际上它将是所有连接的总存储量的两倍(因为每个连接将存储在两个表中)。这也意味着我必须确保两个地方的连接信息保持同步(每个“from”连接在适当的表中都有一个对应的“to”连接。这显然不是理想的，但这确实意味着，当我加载一个用户表，我只需要加载一个‘连接’表，并拥有我需要的所有信息。这也带来了一个单独的问题，即连接对象的创建。因为每个用户表都有一个所有连接的列表，所以有两种机会来创建一个连接对象。但是，连接对象(旨在促进记录之间的通信)只应创建一次。这意味着我必须设计一个通用的缓存/工厂对象，以确保每个连接只创建一个连接对象。

有没有人想出更好的方法来做这件事？一旦我致力于一个特定的设计模式，我就会坚持它，所以我想确定我已经想出了最好的设计模式。

我还将注意到，我目前的备份存储是SQLite。不过，我编写该程序的目的是不依赖于特定的后备存储，方法是引入适配器层，将数据检索与程序的其余部分分离开来。所以备份存储可以是任何东西，甚至是一个简单的文本文件。我只使用后备存储存储和数据检索，没有其他。我不使用任何特定的数据库/SQL关系特性，也不使用数据库执行计算(聚合或其他)。所有这些都是在程序逻辑中处理的。

Answer 1

除了#8之外，您的所有需求都是由关系数据库实现的(考虑一下INFORMATION_SCHEMA，这是一种标准的关系数据库特性--信息模式包含描述数据库中的表、它们拥有哪些列等的视图)，您的应用程序将很好地处理INFORMATION_SCHEMA数据)。

多亏了#8，您基本上已经将自己逼到编写自己的关系数据库引擎上了。

听起来你在实施访问.实现它自己的关系数据库(Jet)；它也很糟糕，因为实现关系引擎相当困难(如果您受Access所具有的约束的话，则更多)，而且最终，访问并不能使困难的事情变得简单。

当然，在另一个数据存储之上实现关系数据库引擎可能会简化事情(例如，Berkeley DB对于实现RDBMS很有用，而且Berkeley DB无处不在。(参见我最近给出的一个相关的答案)，但我会仔细考虑需求#8和项目的可行性。