So, I’m working through implementing another subdomain site for athas.org. It’s going to be an implementation of a database for various 4th edition stuffs. Powers, feats, races, monsters.
Implementing the basics is fine, and easy enough to get through. The tricky part comes in with editing, and versioning.
Because of the way things are structured, I’m dealing with a very broken up set of relationships. Anybody who’s dealt with database programming would know this is a pretty normal situation…
For example: a Race has many RacialTraits, which can in turn have one Power. Not a difficult structure, in the normal case, but it involves three tables. The issue comes in with versioning … keeping track of, and retrieving, old versions of the Race.
Now, I can think of a couple solutions, but they’re all ugly. Every table involved has a shadow _versions table, or I abandon relational databases completely, and try to use a Document database (they’re all very immature at the moment, and, while it’d be an interesting experement, I don’t know that I want to rest major features of the site on one …)
So, before I go banging my head against the wall on this … does anyone even care? Is it necessary to have the ability to go back in time and look at older versions of a race or a feat or a power?

I say ignore past versions. At least on the site. They don’t all need to be accessable. People can keep what they want, if they want to.

I agree with CN.
Once a new version is agreed upon, the past version is no longer required.
It should certainly be kept (in an archive somewhere) but remotely and not publicly accessible seems fine to me.

I agree that version tracking is not necessary.

I agree with Jon (and CN) but wehn a version id agreed upon there can be an “export” of this one on a text/xml file. Just to have a hard file to store away with year,month,day, hour,minute (Mul 2008-06-30 12:33.xml)
This system will have the file to fallback as old version and the files are automatically sorted.