No, you don't. Trust me. Learn relational theory, THEN learn MySQL, not the other way around. Otherwise you will build something that is harder to maintain.
It's not that complex. Grab a decent SQL/Relational theory book and get crackin'. You'll thank me and yourself if you take the time to do this right. Otherwise, you'll run into all sorts of artifical limits imposed by your design, and then have to throw it away and start over. Been there, done that, got the T Shirt. IT sucks to get three months into a project and realize you now have to start over.
If you're not going to bother doing it the right way, you may as well serialize the data and just stick it in a text file, because what you're talking about doing is pretty much the same thing.
Here's a VERY basic many to many table setup:
create table folks (id int primary key, name text);
create table agency (id int primary key, name text);
create table quotes (f_id int references folks(id), a_id int references agency(id), quote numeric(12,2));
Now, you just insert data into those three tables, and you can get it back like so:
select * from folks f join quotes q on (f.id=q.f_id) join agency a on (q.a_id=a.id);
Then, when you need a new quote, it just goes into the quotes table. Your design will have problems right out the gate with race conditions and scaling, the very things that make people turn to databases. You're trying to design a flat file system on top of a database. If that's the goal, then just skip the database and go to flat files.
