Structuring Tables for Estimates and Jobs - postgresql

Question

I'm working on an app for our office and before I start writing this part of the app I need to get some ideas on the best way to structure my data. The application will allow the sales team to enter an estimate and provide it to the customer. If the customer accepts the estimate it becomes a job and is scheduled for the appropriate day. I need a structure that allows me to historically see the estimate in its original state but allow for change orders once the estimate becomes a job. At the completion of the job I will need to see the entire job including all change orders.
I have thought about having an estimates table, an estimates details table and then, once the estimate is turned into a job, the record is copied to the job table, job details table and then a change order table? This doesn't seem very efficient to me.
Would someone shed some design light on this for me please?
Sample Structure:

Answer 1

What you want is the ability to track changes in your entity from initial creation to the final state. You also need to "look back" to see the entity as it existed at any specific time in the past.
Easy. Though not quite simple. What you need is to version your data. I have mentioned versioning in several answers, so rather than repeat some rather lengthy answer here, let me just refer you to a couple.
https://dba.stackexchange.com/questions/114580/best-way-to-design-a-database-and-table-to-keep-records-of-changes/114738#114738
Which option would be better for historical information of a table?
Sorry for lack of details here, but your question was very general in nature.
Update: There is nothing in estimates that would change over time (though I don't understand why it needs address information), so it must be estimate_details you want preserved over time. But I can't tell if there are multiple details to an estimate. The diagram shows a 1:n relationship so I'll go with that.
The best thing would be to place another entity, say bids between estimates and estimate_details:
create table bids(
estimate_id int not null,
eff_date date not null default current_date(),
...,
constraint PK_Bids primary key( estimate_id, eff_date ),
constraint FK_Bids_Estimate foreign key( estimate_id )
references estimates( ID )
);
create table estimate_details(
bid_id int not null,
eff_date date not null,
product_id int not null,
quantity float,
constraint PK_Estimate_Details primary key( bid_id, eff_date, product_id),
constraint FK_EstimateDetail_Bid foreign key( bid_id, eff_date )
references bids( estimate_id, eff_date )
);
I'm assuming here that no two details will concern the same product. Other bids data could include the date it was submitted to customer, the total price, the date customer responded and whether the bid was accepted.
When an estimate is created, the first bid is also created with the same ID as the estimate and the effective date, which could be the date work started on the estimate or other meaningful date. Details link to the bid using the estimate ID and the date of the bid. Then the bid is finished and submitted to the customer. Customer rejects so a new bid is created -- same ID, different date. New details link to this bid.
There could be any number of bids each with any number of details. You can query any estimate at any time just by retrieving the bid for the date you wanted to look at and getting the details linked to that bid.
I'm also assuming that each new bid starts with a clean slate -- that no details carry forward to apply unchanged to the new bid. If that is wrong, if you want to reuse some details from bid to bid, then a slight change can remove the need to duplicate these details across bids.