Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm creating a pretty simple database driven application. Whenever I create a db app, I create classes that mimic the data in the db. Is this good practice?

Am I better off making one big call to the database and populating my objects and working with these objects, or should I retrieve data from the db only when needed?

share|improve this question
up vote 12 down vote accepted

Is this good practice?

It's called Object-Relational Mapping. ORM. It's done all the time.

Am I better off making one big call to the database and populating my objects and working with these objects, or should I retrieve data from the db only when needed?

That's imponderable. First, you haven't defined "better". Second, it depends on the volatility of the data in the database, the nature of your application, and the performance of your ORM layer.

share|improve this answer
+1 for the use of "imponderable". – Adrian J. Moreno Sep 8 '11 at 18:34

If your domain mimics the basic structure of your database, that's usually considered a good thing; it's easy to trace the retrieval and persistence of data as it moves between the data and domain layers. Population via stored proc or view can obfuscate exactly where a particular field comes from in the data layer.

As far as how often to populate data, that totally depends on your application. The more often you "synchronize" data between your app and the DB, the more up-to-date both sides are, HOWEVER, increasing the frequency of data transfer will increase network traffic and server CPU usage (which may make the DB less available for other demands on it from other apps), and may reduce the amount of work that can be undone (if you write changes to the DB immediately when made, instead of allowing the user to "commit" those changes, they can easily make a mistake that immediately goes to the DB and affects other users).

share|improve this answer

If this is a web based application then you should keep in mind "paging" your data result set.

share|improve this answer

I strongly recommend you research using some kind of data abstraction layer. In Perl I use Data::ObjectDriver and/or Moose. Every language has its equivalent. What these frameworks provide is a simple way for you to define the properties of an object, and then the framework will manage interfacing with the database for you. Often there is no need for you to create your database tables, or even write a single line of SQL code. Not only does this make the mundane task of writing SQL for each of your objects completely unnecessary, but these frameworks also help you solve other potentially large architectural problems, like database partitioning and caching.

Let's just look at Data::ObjectDriver as an example, which I select only because I have experience using it. The source code samples provided by its documentation make the API clear: you define a data structure and a database, and the framework will then create the tables for you make interacting with a recipe for example as simple as:

my $recipe = Recipe->new;
$recipe->title('Banana Milkshake');

my $ingredient = Ingredient->new;

Now here is one more advantage of using a framework like this: one of the things Data::ObjectDriver does for you automatically is to interface with a memcached server should one be present. This automatically offloads a lot of traffic from your database to a low-latency caching system over the network. This ability and others are capabilities you get "for free." And from the big picture point of view, a developer should never bother themselves with reinventing the wheel -- unless the wheel you need has not yet been invented. :)

Now, let's return to your question.

Am I better off making one big call to the database and populating my objects and working with these objects, or should I retrieve data from the db only when needed?

My answer to this question is therefore, don't worry about it, but only if you are using a good data abstraction layer. A good data abstraction layer will have addressed many scaling problems and challenges already, or least provide specific remedies for common problems you might face.

If you find that you must write this code yourself, then I would err on the side of simplicity. Keep your database queries simple, even if that means requiring more of them for any given request. Then use memcached to cache the results of your query. That way, even if it takes 100 queries to build a single object, then so be it. The first time through, generate the 100 queries. In subsequent requests, you won't hit the database at all.

share|improve this answer
Nice job on using a recipe example, I'm making a small site for my wife that she can store and view her recipes. – David Peterman Sep 8 '11 at 20:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.