Jump to content

  • Log In with Google      Sign In   
  • Create Account


Database Persistence


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
9 replies to this topic

#1 Telios   Members   -  Reputation: 398

Like
-1Likes
Like

Posted 13 February 2012 - 12:01 PM

Hiya,

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

Thanks :)

Sponsor:

#2 thok   Members   -  Reputation: 662

Like
1Likes
Like

Posted 13 February 2012 - 12:34 PM

Hiya,

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

Thanks Posted Image


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?

#3 frob   Moderators   -  Reputation: 18836

Like
1Likes
Like

Posted 13 February 2012 - 01:13 PM

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?
Check out my personal indie blog at bryanwagstaff.com.

#4 Telios   Members   -  Reputation: 398

Like
0Likes
Like

Posted 13 February 2012 - 01:58 PM

Thanks for the answers Posted Image

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 Posted Image

#5 Telastyn   Crossbones+   -  Reputation: 3718

Like
1Likes
Like

Posted 13 February 2012 - 04:06 PM

The Repository is the common pattern name given to the wrapper around building/saving your entities from/to the data access tier.

#6 meeshoo   Members   -  Reputation: 508

Like
1Likes
Like

Posted 14 February 2012 - 07:46 AM

You mean something like this?

#7 TheTroll   Members   -  Reputation: 882

Like
1Likes
Like

Posted 14 February 2012 - 11:27 AM

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.

#8 Telios   Members   -  Reputation: 398

Like
0Likes
Like

Posted 14 February 2012 - 12:09 PM

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.

#9 LorenzoGatti   Crossbones+   -  Reputation: 2511

Like
0Likes
Like

Posted 15 February 2012 - 03:09 AM

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.
Produci, consuma, crepa

#10 Serapth   Crossbones+   -  Reputation: 5178

Like
0Likes
Like

Posted 15 February 2012 - 10:45 AM

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...




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS