Database design/structure for address details
This is a spin-off from your option two.  It uses two design patterns, namely class table inheritance and shared primary key.

In addition to having two tables, one for companies and one for persons, have a third table, called contacts, that is a generalization of companies and persons, regardless of type.

Contacts.ID will be the usual kind of primary key, probably some kind of autonumber.  Data that pertains to companies and persons alike can be stored in this table.

In the Companies and Persons table, don't include an ID field to use as a primary key.  Instead, declare Companies.ContactID and Persons.ContactID to be primary keys in their own table, and also references to Contacts.ID.  This has the nice effect that it enforces the one-to-one nature of the IS-A relationships, namely a company is a contact and a person is a contact.  It also means that you can use ContactID in any other table and refer to the contacts and also to the companies table or the persons table, as the case may be.

Data that pertains to person, and only to persons, goes in the persons table.

Data that pertains to companies, and only to companies, goes in the companies table.

You can have a ContactsAddresses table that contains ContactID and AddressID so as to provide a many to many link between contacts (whether persons or companies) and addresses.