Re^3: In search of an algorithm for loading cyclic graphs

I'm not understanding something because that looks like you're creating a table for each node type and the rows of said tables are the edges.

Personally, I would create the tables for the node types and have a completely separate table that actually demonstrates the links between the nodes. I would also treat the nodes both in one tables (called nodes) and in their separate tables who FK to nodes. Kinda like a base class and child classes. That way, you can handle it as a 3-table graph when convenient, but you can also get to the data when needed.

In general, if you think something isn't in Perl, try it out, because it usually is. :-)
"What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"

Comment on Re^3: In search of an algorithm for loading cyclic graphs

Replies are listed 'Best First'.
Re^4: In search of an algorithm for loading cyclic graphs by samtregar (Abbot) on May 17, 2005 at 18:43 UTC
I'm not understanding something because that looks like you're creating a table for each node type and the rows of said tables are the edges. You've got it. The only part you're missing is that isn't "just" a graph system. It's Krang, the purpose of which is not to be a general graph implementation but rather to publish webpages. The fact that dumping and loading data is essentially a cyclic-graph-loading problem is more a side-effect than a design goal. In this case each node type is a completely different kind of data - stories, templates, media, categories, users, etc. The links are forgeign keys in the tables, category_id in the media table for example. Does that make sense? -sam	[reply]
Re^5: In search of an algorithm for loading cyclic graphs by dragonchild (Archbishop) on May 17, 2005 at 18:52 UTC
So, the links are literally that - actual weblinks. ponders Either way, it doesn't matter. Create a links table and load that after loading all the nodes in their various types. That's the cleanest solution. Loading the links at the same time as the nodes is going to run into problems with cycles. But, you already knew that. An alternate solution is what Data::Dumper does and that's to keep track of what nodes have been seen before and stop following the tree when you find somewhere you've been. I don't know if that will work, given the code you've already written. In general, if you think something isn't in Perl, try it out, because it usually is. :-) "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"	[reply]
Re^6: In search of an algorithm for loading cyclic graphs by samtregar (Abbot) on May 17, 2005 at 18:58 UTC
So, the links are literally that - actual weblinks. Sometimes. Story to story links are usually real links. Story to user links, for example, aren't. They link a story to the user that created the story. There are more non-weblinks in the system than weblinks. Both your solutions are reasonable. In fact, what I'm doing now is sort of like both. Neither is what I'm after here, but maybe what I'm after doesn't exist. -sam	[reply]