I'm learning programming in school and I have this question that's bugging me about data structures and transferring the information stored inside them to databases. We're doing just small systems - registration for an event, point of sale for a local restaurant, sales and inventory, etc

Let's say someone registers himself, should it be passed into a data structure and then into the database, or should it just be transferred directly to the database?

  • Other answers cover the specifics, but one thing to note is that each feature has a benefit and a cost. As a beginning programmer, you may not have a feel for if the cost is worth it, but it will come with time. On most large projects, you will want a Data Access Layer, Business or Domain layers, and other things. But in your school project, I wouldn't worry about it too much unless you have a need for it or it will help your grade and you have time for it. May 2, 2012 at 15:49

2 Answers 2


At its most basic, what you need to develop to transfer data between data structures in memory and persistent data stores (files, DB, whatever) is a Data Access Layer or DAL. This is one of your "application tiers" in a properly-constructed N-tier application. Objects in this tier know how to create data structures from DB data, and conversely to convert a properly-populated data structure into DB data, so that objects generally lying outside this tier don't have to have this knowledge.

There are several models for building a DAL tier. The most common in my experience is a centralized "front door" that can accept any request to read or write data and produce any needed data structure. This pattern is called the "Repository". You would make a call to this object along the lines of:

int myObjectId = 1243;
MyObject myObjectInstance = myRepository.RetrieveById<MyObject>(myObjectId);

... and then myObjectInstance would be populated with the data from the table representing MyObject records, with the identifying key that we specified. How that happens exactly, nobody outside the Repository really has to know; you could dynamically construct a SQL statement, use a Data Access Object that knows specifically how to retrieve MyObject instances, or you could do as Oded states and use a third-party library called an Object-Relational Mapper or ORM which abstracts away all the details of how the retrieval happens.

  • Thank you. Do you have any recommendations on books to read on the topic?
    – Daryll Santos
    Apr 19, 2012 at 1:42

The aim is to store data into the database. If the data structure isn't needed for your use case, then don't use it.

In most apps I have worked on, data structure would be used only because I am working with code that expects (or needs) a data structure to be passed around between different business logic methods before the data can be saved to the database.

  • Oh, okay. I sort of get it, if it's not worth the overhead, then don't use a data structure?
    – Daryll Santos
    Apr 19, 2012 at 1:43
  • @DaryllSantos yes, but I would also like to stress on the "not needed" part. I have seen cases where, even though only one thing changes, the entire "set" get saved. For example: User Settings in some application which lets its user set some settings for different functionality. If a user changes only one Setting, there really is no point to load and save all of them. It only opens up the possibility of more maintenance issues in future.
    – rk2010
    Apr 19, 2012 at 14:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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