4

This question asks about storing a single graph in a relational database. The solution is clear in that case: one table for nodes, one table for edges.

I have a graph data structure that evolves over time, so I would like to store "snapshots" of this graph in a database. I imagine having hundreds of such snapshots.

One solution is to create a whole new table pair of nodes and edges (as above) for each snapshot. Is there a better solution?

EDIT: It was asked what I would like to do with this database. I believe that I will not be doing any querying except to dump all of the graphs to MySQL from C++ and then load it all back into C++ data structures. So I'm looking to use MySQL for storage and not for efficient random access / searching.

Community
  • 1
  • 1
Alan Turing
  • 11,403
  • 14
  • 66
  • 114
  • Could you add some detail about what you'd like to be able to do with your historical graphs? Will you need to be able to run queries/searches against them? – Jeff Swensen May 10 '11 at 01:15
  • I believe that I will not be doing any querying except to dump all of the graphs to MySQL from C++ and then load it all back into C++ data structures. So I'm looking to use MySQL for storage and not for efficient random access / searching. – Alan Turing May 10 '11 at 09:41

1 Answers1

5

You need a table 

 graphs = (graphid, dateofsnapshot or other things unique to the snapshot)

and you need the nodes and edges tables but with a foriegn key reference to the graphs table. This way you can have an arbitrary number of graphs in the database.

Vincent Ramdhanie
  • 98,815
  • 22
  • 134
  • 183