Good/Bad coding??

I am currently writing a program for a Uni project that acts as a video rental store system.

I am about to write the part which will create a customer rental histroy file. The main problem I face is... how do I read and write a unknown number of histroy records for each customer?

So... my question is; does the method (to follow) sound like a good way of writing this? or is it totally lame and bad programming practice?



The program:

Currently there is a customer file, each customer has a unique number to identify them.

I then plan to create another text file which holds history data. If a customer had rented three films previously, then the history file would look like:

1003 3
0F
3A
7B

where the first two numbers are the customer number, and total numer of history items respectively. And the three hex numbers are the ID's of the films. (The formatting may vary, this hasn't been written yet, its ust an example).

The program when asked for the history of a customer, would look for their ID number, it would then read the number of history items that customer has. Then memory would be allocated to read into a dynamic array the film ID's. The program would then have to cross reference each film ID and retrieve the title of the film from another text file containing all the films.

-----------------------------------------------

Obviously I want to get good marks for my program, and so I don't want the program to be pointlessly long and complicated.... is there a better way of doing what I am doing? or does this seem reasonable??

Many thanks

Why use flat files?

If you use a database you can have a unique ID for each customer in a customer table. A film table that holds a a unique film ID and the title and then a Rental table which would hold a record for each rental. Each rental record would contain a unique rental ID (just for primary key purpose), store the user id, and the film id that was rented. This could be extended to store date issued and issue length etc. Flat files are not really flexible or fast enough for this kind of system

Inevitably.... the next question is how exactly??


As I understand from reading books and the FAQ on linked lists, this would mean (correct me if wrong) that all of my data is loaded into memory?

I say this, because to have a pointer to the next item, you would need it to have a memory location would you not?


With this in mind, that would mean that as more films are added to my database, and more customers rent more films etc, I would eventually be loading up a lot of data.

So, is this the best way to do it?? is that how you guys would do it presented with the same problem?? are there any other options?

Many thanks for the help, all this correspondance will go into my final report and help me A LOT.

Computerfreaks

You don't have to load the entire database each time you run your program. As the user selects the customer whose history is to be viewed, you fetch the data relevant to that customer only. There are functions like SQLfetchData() etc to get data from the database. This I do in MSVC++6.0 and don't know whether it works with gcc etc or not and what are the other equivalent functions.

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.

That answers a lot for me. Thanks very much!

You get the honour of appearing in my final report ;)