Hey there! Sign in to join this conversationNew here? Join for free
    • Thread Starter
    Offline

    0
    ReputationRep:
    Hey guys, I was wondering if anyone could answer this question for me. I'm starting to learn about classes and objects in my computing A2 course, what I'm wondering is what's the advantage of manipulating data in an object as opposed to a relational database?

    For example (from the book). If I built a class called BankAccounts, and built an object when I create an account. It doesn't make sense to me why I would do this instead of connect to a database and add it on to there.
    It may just be a bad example in the book, can anyone suggest a more practical example of where I would use this?

    Thank you.
    Offline

    16
    ReputationRep:
    Well, why do the two have to be mutually exclusive? In a typical scenario, you'd have your database in the background with all of your information and in your application code you would create objects pertaining to the particular records you are working with at a given time, which gives you a higher-level, well-defined instance of your objects which both:

    a) Makes them neater and easier to work with in application code.
    b) Removes the necessity of making repeated, computationally expensive database queries.

    This way, you can work with your information locally and in a structured manner, interfacing directly with the database only when necessary.

    You will always need some kind of persistent storage like a database, since you can't simply store all of your info in RAM and have it disappear when you end your program, but at the same time you will always need a local representation of your data for when you are using it in an application, which is where object orientation comes in.
    • Thread Starter
    Offline

    0
    ReputationRep:
    (Original post by Planto)
    Well, why do the two have to be mutually exclusive? In a typical scenario, you'd have your database in the background with all of your information and in your application code you would create objects pertaining to the particular records you are working with at a given time, which gives you a higher-level, well-defined instance of your objects which both:

    a) Makes them neater and easier to work with in application code.
    b) Removes the necessity of making repeated, computationally expensive database queries.

    This way, you can work with your information locally and in a structured manner, interfacing directly with the database only when necessary.

    You will always need some kind of persistent storage like a database, since you can't simply store all of your info in RAM and have it disappear when you end your program, but at the same time you will always need a local representation of your data for when you are using it in an application, which is where object orientation comes in.
    Ahh of course. I feel silly for not realising this sooner!
    Mind you, I am now going to burn my book for not mentioning this at all...

    Thank you for your help
    Offline

    16
    ReputationRep:
    Yeah, it's a fairly common error in a lot of programming tutorials to focus purely on the code and neglect how applications fit into the big picture, which is kind of understanding when you're just learning the basics of class-based programming but, at the same time, can leave a lot of things seeming fairly pointless.

    Glad to help
    Offline

    14
    ReputationRep:
    I should mention that there are such things as object-oriented databases, which you may find better than relational databases for persisting object-oriented state
 
 
 
  • See more of what you like on The Student Room

    You can personalise what you see on TSR. Tell us a little about yourself to get started.

  • Poll
    Did TEF Bronze Award affect your UCAS choices?
    Useful resources
  • See more of what you like on The Student Room

    You can personalise what you see on TSR. Tell us a little about yourself to get started.

  • The Student Room, Get Revising and Marked by Teachers are trading names of The Student Room Group Ltd.

    Register Number: 04666380 (England and Wales), VAT No. 806 8067 22 Registered Office: International House, Queens Road, Brighton, BN1 3XE

    Quick reply
    Reputation gems: You get these gems as you gain rep from other members for making good contributions and giving helpful advice.