Database relation of purchased items

Question

I'm trying to come up with a database relation to keep track of purchased items that will be used for look up afterwards--for example ebooks. Ignore the ellipses--they represent miscellaneous data such as timestamp, etc...

Here's the table I have right now:

purchased:
transaction_id(int)(pk)(auto_inc) | username (varchar) | purchases (text) | ...

In this design, the column "purchases" is just a string of text that would contain the item_id of items purchased, separated by commas. Simplified example: "book1, book23, book5, book8".

In a successful transaction, this query would insert the transaction data into the "purchased" table:

INSERT INTO purchased VALUES (null, username, purchases, ...)

---

From this point on, two things can happen:

1. The user can lookup what ebooks they've purchased
2. The user can make another purchase transaction.

If the user (theusername) wants to see their ebooks, the system performs a selection query e.g.

SELECT purchases FROM purchased WHERE username=theusername

which returns a string containing the item IDs.

One a sidenot, is it possible to get an php array of purchases without having to use extra php code, i.e. explode? Can you use something besides the data type "text" in SQL to store a list of items? If not, that's okay.

---

Either way, here's the main problem. Say the user makes another transaction--there will now be two rows in "purchased" that contains the user's purchased items. That means that in this table, the user's purchases are split into multiple rows.

Ideally, I want these purchases to all be in the same row. I can't use an UPDATE statement because each purchase has it's own unique transaction_id.

I was thinking that I could make another table that contains all purchases by a user

all_purchased:
username (pk) | purchases (text) | ...

and whenever the user makes another transaction, the "all_purchased" table would just update its purchases column with the item ID of any new ebooks.

But this table seems redundant because the selection query I mentioned would get the task done.

What would be the best way to structure the database relation(s)?

Answer 1

Considering that you are using relational database -- in there any special reason not to use normalized tables? Here is just one possibility.

This one propagates keys; if you have an ORM of some kind that has trouble with composite keys, modify as in this example.

Answer 2

I think its not a good idea to maintain the purchased book_ids in same row as comma separated values. Better to define a new table as :

  purchased_books:
      transaction_book_id(int)(pk)(auto_inc) | transaction_id(int) | book_id(int)

Also define foreign key relationships of transaction_id and book_id column with their respective tables i.e. purchased and books.

Hopefully, rest of your problems will be solved by using this new table.