Enforce unique addresses or allow duplicates?

Question

We are creating a database with multiple entities that will use mailing addresses. Some of those entities can have multiple addresses while others can only have a single address. We decided to centralize the addresses in a single table called MailingAddress. An example layout is shown below.

Party         PartyAddresses            MailingAddress         Letter
_____         ______________            ______________         ______
PartyID (PK)  PartyID (FK)              MailingAddressID (PK)  LetterID (PK)
PartyName     MailingAddressID (PK,FK)  StreetAddress          From
                                        City                   To
                                        State                  Subject
                                        ZipCode                MailingAddressID (FK)

We are having some debate over whether to only allow unique addresses in the MailingAddress table. For example, if a Party has address 123 Main St, Anywhere, NY and a Letter has an address of 123 Main St, Anywhere, NY, then only have a single address record for 123 Main St, Anywhere, NY.

One argument is that having any given address only once reduces the number of address records and is better "form". Basically, improved storage and table size.

The other argument is that, while argument one is theoretically sound, the benefit is outweighed by the practical downfalls of this approach. First, the performance penalty of having to code around the uniqueness. For example, either handling the unique constraint violation on INSERT and querying for the exiting record, or querying for the existing record and inserting a new one if not found. Additionally, if a record is updated, this process would need to be repeated because the existing address would need to be left intact in case it is being used by another entity. Second, the increased risk of having to write this code. It increases the possibility of a bug being introduced that updates and existing address that is used by another entity.

In your experience, which is better? How does this relate to normalization?

EDIT:

Actually, I misrepresented the PartyAddresses table, but have corrected it above. It is actually meant as an "extension" table to allow a mailing address to be related to a party. Basically, a Party can have multiple addresses, but in the current design, and address can only belong to one party. Whether this is changed to a many-to-many relationship depends on the answer to my original question.

Yes, the mailing address can be updated. There is actually no relationship between letter and party. I should have explained that they are used by two different features of the system. There are numerous entities in this system that need to have addresses assigned to them. I included two here for illustration purposes (Letter and Party). There are more, but the fact that different entities have the same address does not make them logically related in this system.

Answer 1

The design should reflect the needs of the application you are going to develop. Some information I need to clarify:

I see in your design that Party - MailingAddress has a many-to-many relationship: A party can have multiple Addresses and multiple parties can have the same mailing address. Is that what you expect to happen?

When you want to get a letter, do you take care about the party involved in that letter? If you design your database as you described, we cannot know which party is involved in the letter.

Can the mailing address be updated? Or you only insert a new one when a new party with new address is created or an existing party changes its address, and delete one when the last party with that address is deleted? If you plan to update the mailing address sometimes, when you queries the old letters the addresses information received is also changed.