Jump to content
  • Advertisement
Sign in to follow this  
beebs1

Database Persistence

This topic is 2495 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

Advertisement

Hiya,

Are there any standard patterns for database object persistance I can look up?

Thanks smile.png


By 'object' do you mean literally serializing an object (state and all) to the database? I think in general that's a bad idea. But then again, what is the context of your problem?

Share this post


Link to post
Share on other sites

Are there any standard patterns for database object persistance I can look up?

Yes, many. So many, in fact, that people can get advanced degrees on the subject.

Is there some specific need you are trying to solve?

Share this post


Link to post
Share on other sites
Thanks for the answers smile.png

I'm looking for a way to retrieve and persist database entites (as classes) without making SQL calls directly in the application logic. For some classes, I'd also like to cache them.

I'm thinking along the lines of a 'Manager' or 'Store' for each entity type, which performs the SQL calls and can cache the objects in an internal map of { ID -> Object } as needed.

As an example:

class OnlineProfileEntity
{
unsigned int getAccountD() const;

void setAuthTicket(const Ticket&...);
const Ticket& getTicket() const;
// etc...
};

class OnlineProfileStore
{
public:

// does the actual DB access.
OnlineProfileStore(DatabasePool& databasePool);

// get from the cache, otherwise query the database
smart_ptr<OnlineProfileEntity> getProfileByID(unsigned int id);
};


I was just interested in any common patterns there might be...

Thanks again smile.png

Share this post


Link to post
Share on other sites
The Repository is the common pattern name given to the wrapper around building/saving your entities from/to the data access tier.

Share this post


Link to post
Share on other sites
The reality is that it is easier to just define your database tables with the data you need to store, and stop trying to store "objects". If you store all the data stored by the object is not hard to create a constructor that takes that data and recreat the object at any time.

Share this post


Link to post
Share on other sites
Thanks for the replies.


You mean something like this?


Not quite, I think - I'm just looking for something that will let me refactor the SQL queries from the class that parses network packets from the TCP buffer...


The reality is that it is easier to just define your database tables with the data you need to store, and stop trying to store "objects". If you store all the data stored by the object is not hard to create a constructor that takes that data and recreat the object at any time.


True - I'm not trying to do this exactly. More something that sits between the application logic and the database code, and can return entities from the database with some form of caching.

Share this post


Link to post
Share on other sites

True - I'm not trying to do this exactly. More something that sits between the application logic and the database code, and can return entities from the database with some form of caching.

If caching objects you load from the database to speed up later requests to "load" them again is useful, maybe other parts of your application are being too forgetful with the objects they load; references should be retained properly instead of loading the same objects repeatedly.

Ask yourself if generic caching in the database access layer is really the best approach; it might be appropriate or good enough, but maybe what you need is transaction processing, without persistent objects, or smarter and specialized data structures to manage persistent objects in useful ways that go beyond the basic load-store-cache functionality of the underlying ORM.

Share this post


Link to post
Share on other sites

The reality is that it is easier to just define your database tables with the data you need to store, and stop trying to store "objects". If you store all the data stored by the object is not hard to create a constructor that takes that data and recreat the object at any time.



Or of course, you can do the opposite and not use SQL. The NoSQL movement, even the object database are rising in popularity. If you are trying to store non-tabular data, it makes no sense to use a table based database.

MongoDB is certainly one of the most popular, with some pretty serious support behind it, but there are a dozen or so viable options. MongoDB works with Key/Value pairing and might be a much better fit.


That said, everyone and their dog are getting into this space, Amazon, Google, Oracle, Microsoft ( sorta ), etc...

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!