I did the history problem by making a separate table with all of the values that I wanted to show to the user, all of which were the same as that of my portfolio page but instead would not be deleted when stocks were sold. So I have a couple questions about this:
1) Since I never need to manipulate data afterwords for history did I need to create a whole new table at all? Maybe this is a dumb question, but if I could somehow store the information in portfolio I could (maybe?) use it for buy/sell and history combined?
2) If I do need the extra table, can I join the tables like Malan shows in his lecture? In the example in the lecture, we wanted to not have to repeat similar zip codes, so we stored the zip codes in a separate table and later joined the users table with the zip code table where the users table had the foreign "zipcode_id" which meant that a zip code could be represented as an integer in the users table. But how could I limit redundancies for this problem considering that my history and users table have identical fields?