Are there any standard patterns for database object persistance I can look up?
Thanks
Database Persistence
Author
Hiya,
Are there any standard patterns for database object persistance I can look up?
Thanks
Are there any standard patterns for database object persistance I can look up?
Thanks
Hiya,
Are there any standard patterns for database object persistance I can look up?
Thanks
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?
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?
Author
Thanks for the answers 
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:
I was just interested in any common patterns there might be...
Thanks again
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
The Repository is the common pattern name given to the wrapper around building/saving your entities from/to the data access tier.
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.
Author
Thanks for the replies.
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...
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.
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.
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.
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...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
