Jump to content
  • Advertisement
Sign in to follow this  
laztrezort

Validating references between data objects

This topic is 2902 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a collection of data - I call it a database, but it is not formally a database - that is organized into various collections of varying objects. For example, I may have:

ObjectACollection - an array (or collection) of ObjectA's
ObjectBCollection - an array (or collection) of ObjectB's

and so on. This database is user editable - a user can add and remove objects into the various collections, filling in the necessary data fields for each. Some objects may reference others. For example, a particular ObjectA may reference a particular ObjectB. The graph of these object references may get somewhat complex, though there will be no circular references.

Note that when I say "reference" I don't necessarily mean a reference as in holding a pointer. It may be an array index, or a dictionary key - I haven't implemented any of the object collections yet.

Here is the problem: as an example, a user may, at some point during the editing, want to remove an ObjectA from ObjectACollection. This would invalidate any other object that references that particular ObjectA. Ideally, the user would be notified of this, either not allowing deletion or handling the validation automatically and safely.

My naive solution is to have a DatabaseManager that holds all of the object collections, and knows all about their links. It would step through all of the collections and validate whenever necessary.

I've long ago learned that the naive solution is rarely the cleanest one, so I figured I should go fishing for some possible advice. In particular, I'm worried that the system may need to be updated (new objects and reference links added) at a later time, and the DatabaseManager will become a monstrous object full of spaghetti :)

Of course, on the flipside, I've also been known to over-think problems, so perhaps this is a perfectly valid solution.

Some notes in case it is important:
1. I'm using C#
2. Speed, memory optimizations are not (should not be) an issue.
3. Other than adding/removing objects, the DataBase has little else functionality.

So, to reiterate, does the naive solution outlined above seem reasonable, or are there known/preferred/tried-and-true methods or patterns out there better suited? It seems like this would be common scenario in certain applications, but it's new to me.

I'm not afraid of research, so even some search terms would be appreciated.

Thanks!

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by laztrezort
The graph of these object references may get somewhat complex, though there will be no circular references.


Graph without cycles is a most commonly a tree.

A tree node is easily represented using parent and child pointers.

For complex relations, each node may have more than one parent. It then becomes trivial to update relations in either direction.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
Graph without cycles is a most commonly a tree.

A tree node is easily represented using parent and child pointers.

For complex relations, each node may have more than one parent. It then becomes trivial to update relations in either direction.


I guess I noticed the tree-like structure of the data but hadn't considered implementing the whole thing as an actual tree - storing references to both parents and children. That would certainly simplify things, I think.

Storing pointers would make the data harder to serialize, but I suppose the tree could be rebuilt when loading.

Thanks for the suggestion.

Share this post


Link to post
Share on other sites
Quote:
Original post by laztrezort
Quote:
Original post by Antheus
Graph without cycles is a most commonly a tree.

A tree node is easily represented using parent and child pointers.

For complex relations, each node may have more than one parent. It then becomes trivial to update relations in either direction.


I guess I noticed the tree-like structure of the data but hadn't considered implementing the whole thing as an actual tree - storing references to both parents and children. That would certainly simplify things, I think.

Storing pointers would make the data harder to serialize, but I suppose the tree could be rebuilt when loading.

Thanks for the suggestion.


You don't have to "implement the whole thing as an actual tree" with dynamically allocated nodes and so forth. All you have to do differently is change your database code such that if object A references object B, object B knows this i.e. for each object maintain a list of objects that reference it. Then if object B gets deleted it's trivial to update object A.

Share this post


Link to post
Share on other sites
Quote:
Original post by jwezorek
You don't have to "implement the whole thing as an actual tree" with dynamically allocated nodes and so forth. All you have to do differently is change your database code such that if object A references object B, object B knows this i.e. for each object maintain a list of objects that reference it. Then if object B gets deleted it's trivial to update object A.


I thought I might have been over complicating things...

This sounds fairly simple (and obvious, now). I'll try a quick test implementation to see how it goes.

Thanks!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!