I hear yeah. Well. That certainly brings clarity to my question for sure.

From a functional perspective, I've always understood foreign keys to build structure to databases where it will prevent inconsistency with records in related tables.

So there is 1 death recorded in the 'DEATH' table with a FK constraint where if a character record were dropped from the database lets say, would also require that the record in the DEATH table be dropped as well. That way there isnt a Character definition record remaining in 1 table while there isnt in any other. Joins themselves may not address this issue unless the join were specified in a way to address a cascading deletion in the even of a drop in either of the tables being joined. But i can only assume in this case if it were 2 tables, 2 drop statements would have to be scripted out anyway. This, is regardless of whether there is a foreign key constraint or not. But at least the constraint prevents the deletion of a parent record without including the child.

But of course, I'm sure you already knew that.

In my opinion the lack of foreign key constraints when dealing with related tables would leave a database highly vulnerable to inefficient use of space and a redundancy in code.

I know this is going off topic but its alright i guess. :)

As far as I know, there are not tables to track things like death*, or records-over-time. The database represents the state of the world right now. It is not "4 dimensional" if you get what I mean.

Transaction data can be archived in such a way that you can rewind the current state of the database without actually taking a bunch of full copies of the database, as long as they are rolled back in a LIFO manner.

* Tracking a corpse object does not equal tracking a death

EDIT:
For more info about proper schema design w.r.t. foreign keys, etc, read up on database normalization. It's good to have a source of truth in relational databases and have other tables refer to that, rather than copy in such a way as to allow inconsistencies to crop up.

The archiving part, as I described it, is generally referred to as data logging. It does track the DB but the core tables should not really know/care they are being tracked.

Very nice. Ty Jorg.

Yeah I (believe it or not) would have just assumed rollbacks are on LIFO basis. But there goes my mental "End User" laziness creeping in. xD

Ill drop a line in-game to wave hello sometime! Good to know there is another "see-er of the machine world" who capitulates to the other side every once in a while! haha