Alternatively I can create multiple addresses and give them all the same AddressId.

This is not a good idea at all. The AddressId supposes to be a primary key in your Address table.

Foreign Key

Use foreign Key relationship between customer and address tables, if customer may have multiple addresses associated to him/her.

Do enforce foreign key relationship between customer and its addresses by CustomerId being a primary key in Customer table and foreign key in Address table. This will ensure that no orphan records will be left, when customer record is deleted or in-activated.

One-to-many relationship diagram:

In the case if same address can be assigned to different customers, aka many-to-many between customer and addresses, do use a third table CustomerAddress (junction table). Junction table should save pair of (CusomerId, AddressId) and any other related information specific for this combination.

For example, in below diagram we have many to many relationship between Orders and products.

For more references on DB design patterns look here.

Many-to-many relationship diagram:

the second option (addressId that are not unique) is actually the same as using customerId in Address with the only difference that customer needs another column

on this alone I would just use the foreign key relationship with customerId

A few things:

• An address can exist but no one lives there
• A person can have multiple addresses (home, job, other job, summer cottage)
• A company or person could be at an address
• Two or more people can share the same address
• Mom could live at Address1 and Dad could both work and live at Address1
• Global mailing addresses are complicated. You should break them up into components.
• You might want to abstract many kinds of addresses (web, email, telephone, mailing) into one supertype, so that you can point a foreign key to any kind of address. For example, you might want to ship an order line to an email address for a digital good, and another order line to ship to a mailing address.

So you need to know about the Party Model, so that you can abstract people and organizations, and you need to know about Table Inheritance, so that you can do abstraction in a database.

Your data model should look like this:

Party -< PartyAddress >- Address -< MailingAddressComponent

--

Party{
  type [individual, org]
  name
  ...
}

PartyAddress{
  party_id
  address_id
  role [home mailing, business fax, home cell]
}

Address{
  type [web, mailing, email, phone]
}

MailingAddressComponent{
  address_id
  type [street, city, town, hamlet, province, state...]
  value
}