It really depends on what you need to store. Really, you need customer info, and what items they rented, and when. You need a seperate list of your movies. I don't really see the point in having a seperate list of all rentals, at least in memory, with information on who rented the movie and such.
If you need that, you can just poll through your customers and tally it up some time. But since there's such little use for it, I personalyl wouldn't probably do it. Probably something like:
Code:
Customer Data:
ID#
Name
AccountInfo { account creation date, expiriation date }
ListOfRentals
RentalData:
Movie#
RentalDate
MovieData:
Movie# {unique identifier}
MovieName
MovieStuff { description of, actors, purely optional info }
The first record describes our customer. It is simply a structure which contains that information, as well as a linked list of 'RentalData'.
The second record is a structure which is to be linked list containing simply the unique identifier of the movie, and the date it was checked out.
The third record would be all of the movies and whatever information you wanted to provide.
There are actually many ways to do this. You could expand your 'RentalData' to include slightly more info, such as the name of the actual movie rented, when it's in memory. This way when you scan through all the stuff they rented, you can see the name of the movie, instead of just the number.
However, when saving their rentals, all you save to disk is a date and the movie ID#. Anything else is just a waste. You translate that in memory to whatever additional information you want the rental record to hold. (Such as movie name, as mentioned earlier.)
The list of rentals could however when saved, be a seperate entity. This would be parsed at load time, and they'd be linked to the customer. Either that, or you simply make a seperate file for each customer, and just append all of their rentals onto the file. Very simple way to handle it. (Unless you're using a "real database", and not just something you throw together.) Make the file name be the customer's ID#. You could then just load that customer up when you need to do something with that account. Again, this is a very simple way to deal with the issues of customer management. Also, this prevents one corrupt file from trashing all of your customer information.
Quzah.
