mysql - Should i stock "quotation_request" as a table on my DB? -

i'm working on simple db.

imagine i've table customer , table seller.

the customer able request quotation products

there simple form allow customers select products , submit quotation.

now, should create table : "quotation" , store quotations (with id_quotation..etc)?

thank all

without knowing of business rules govern requirements of database, perhaps following design answer question , explain few concepts in process.

in database terms, entity person, place, or thing want collect , store data. description can see 2 entities: seller , customer. important since entities identify conceptually become database tables in own right.

the seller table should contain data applicable sellers. thus, qualities (attributes) sellers want store become columns in our seller table. each row (record) in seller table represents individual seller. each individual seller uniquely identified in seller table unique value stored in it's primary key column, can name seller_id.

a simplified version of such table this:

in similar manner, customer table should contain data applicable customers. qualities (attributes) customers wish store become columns in customer table. each row (record) in customer table represents individual customer. each individual customer uniquely identified in table unique value in it's primary key column, can declare customer_id.

a simplified version of table:

i'm guessing business rules state customer able request number of products, seller, number of times...since surely seller want many sales , customers possible!

how can express , record interactions (relationship) between seller , customer?

this done new kind of entity: composite entity. becomes new table, having it's own primary key, , contains seller_id , customer_id foreign keys. foreign keys in table connect (relate) seller table customer table.

we can name new table quotation (if preferred name). each row of table intended capture , record each , every individual transaction between customer , seller. columns (attributes) of table data apply transaction between customer , seller, such amount or date of sale.

a simplified version of composite entity:

note foreign key values exist in table must exist in respective tables primary key value. is, foreign key value cannot entered table unless exists primary key value in it's own table. important, , called referential integrity - ensures there no record of customer purchasing non-existent seller, etc.

in example above can see builder b requested quotation acme construction in amount of $3500.00. requested quotation @ time amount of $1800.00. else reveal? existing customers have ordered something. acme lumber has not made sale @ (yet), etc.

a design such enables database store number of transactions between sellers , customers. likewise, supports addition of number of new customers , sellers, if have not sold or purchased yet. queries can run reveal sellers have sold or least, , on.

good luck studies!