Hi Riche,
Indeed. The idea is tat you store all information only once.
So you'd have a table with all parts that you could potentially need / use.
Another table that stores details about a customer
Another table that stores the current repair being made, with a colum for the customer_id to be stored
And another table, which links the repair to the parts (Which would only require 2 or three colums:
Repair_Identifier; Part_identifier; (Table_Record_id: Not required)
This way if anything changes in your database (Say the customer wants his second name on the bill too), you'd only have to change one thing.
However, once you start using this database as an archive of all the transactions, you might want to create a table to store all individual charges made to a customer, as descriptions and charges may change (Unless you do not UPDATE the records in the PARTS table, but you add new parts to it, whenever costs of a part, or descriptions of parts (e.g., serial nrs) change. Otherwise you can never look back into the table and see what you charged customer X in year Y for repair Z.
So: for current jobs, try to replicate as little information as possible; for archive & bookkepping purposes, think how you want to handle changes in the products you sell, and design your tables accordingly.
You will get to work with imploding etcetc. But for now, take a step back, with a piece of paper, and design the database structure. You might want to post it on this forum too. A faulty database design can cause you a lot of trouble in the long run, and designing it properly is worth your time.