basic mysql/data storage question: information architecture, not as much code itself

I'm trying to figure out my first "more complex" SQL application and am having a bit of a hard time conceptualizing the best way to go about something simple. I understand the code, I think, around various concepts but want to know the best way you think is the way to proceed, and more importantly what terms/how to call this method, so I can do more research on it myself without needlessly bothering people!

I am building a WP plugin that will let someone add any number of boxes to any number of "transactions". Basically, transaction 1 can have box 3 boxes called apples, fruits, organes. Transaction 2 can have 10 boxes. And so on. I want a way to show this to the end user in the best way. As a beginner, my (bad, I'm sure) instinct is to have one key called, say, transactions, which is a comma separated list "1,2,3,4,5". Then, have another table where the index is 1,2,3 and for each of these keys i have the various boxes. I grab the first CSV list from the db, "explode" it to an array and cycle through, grabbing the keys from the second table that reflect this #. But in the second table, does each "key" point to other keys? This is where i get confused. Is this the best way to proceed? What kind of code would I need to look for? EDIT: Here is a visual image of what I'm looking for:

Transaction 1: #12878321: Apples, Oranges, Pears
Transaction 2: #11239089: Berries, Oranges, Apples
Transaction 3: #89792834: Spaghetti, Berries, Oranges, Pears, Apples

I would like to display on the page the information just like that. So I need to store the transaction number, the random code, AND "what was purchased" (the boxes in my example above) all to the end user.

I've already done inserts, updates, etc on one table but never conne开发者_如何学编程cted (correct word?) two tables and don't know if thats the way to do it, to create another WP table.

I apologize if this is a strange and long question, but among the 1,000 of tutorials on the web, its hard to understand which one to follow because I'm not familiar with the terms themselves!

---

What you want is (I think) called a "many to many" relationship. These are usually best handled by an association table; the association table simply has two (relevant) columns; the ID of a record in one table, and the ID of a record in a second table. That way, you can create a SQL statement that will find for you all of the "boxes" (records in table 2) that exist for a given "transaction" (records in table 1); you can also create a query that will allow you to find all of the "transactions" (records in table 1) that refer to a given "box" records in table 2.

For this, you need three tables:

Transactions
ID,   Whatever else you keep for transactions

Boxes
ID,   Contents

TransactionBoxes
TransactionID,   BoxID

---

Not sure if I'm understanding your description of the data, but it does sound like it'd be a many-many relationship (many transactions, each with many related boxes).

The basic table setup for something like that would be:

transactions:
    userID - who the transaction belongs to
    transactionID - unique id for the transaction itself

boxes:
    transactionID - which transaction does this box belong to
    name  - oranges, apples, etc...

You don't mention if these boxes contain many other things, but then it'd just be a 3rd table that lists what the contents of each box is.