Design - duplicating properties vs not allowing delete
There are a few issues that come to mind.


A normalized approach (jobs in one table, addresses in another, related only by a foreign key) is desirable from a purely database design perspective. It makes both storage and reporting more efficient.
With this normalized schema, however, you'll want to make sure that an address isn't entered in duplicate (for instance when creating or changing a job). This could typically be the task of a "create job" stored procedure, but you'd have to build some sort of matching logic to merge addresses like 101 First Street with 101 East 1st St, etc. This logic may well be in the GUI, in the form of an "auto-complete" dropdown or similar.
I'm guessing that there could be legal aspects as well: there are juristictions where a person (like a customer) can request that you remove any personally identifiable information about them after your relation ends. If that information includes that you've done business at their street address, then you'd probably want to ask your legal beagles about the legality of retaining a record of addresses even though you've deleted or masked the job data.