Let's say I have two Tables, called Person, and Couple, where each Couple record stores a pair of Person id's (also assume that each person is bound to *at most* another different person).
I am planning to support a lot of queries where I will ask for Person records that are not married yet. Do you guys think it's worthwhile to add a 'partnerId' field to Person? (It would be set to null if that person is not married yet)
I am hesitant to do this because the partnerId field is something that is computable - just go through the Couple table to find out. The performance cost for creating new couple will also increase because I have to do this extra book keeping.

I hope that it doesn't sound like I am asking two different questions here, but I felt that this is relevant. Is it a good/common idea to include extra fields that are redundant (computable/inferable by joining with other tables), but will make your query a lot easier to write and faster? 
Thanks!
['https://Stackoverflow.com/questions/26371381', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/4143394/']
Is there always a zero to one relationship between Person and Couples? i.e. a person can have zero or one partner? If so then your `Couple` table is actually redundant, and your new field is a better approach.

The only reason to split `Couple` off to another table is if one Person can have many partners.

When someone gets a partner you either write one record to the `Couple` table or update one record in the `Person` table. I argue that your `Couple` table is redundant here. You haven't indicated that there is any extra info on the `Couple` record besides the link, and it appears that there is only ever zero or one Couple record for every `Person` record.
How about one table?

```
--  This is psuedo-code, the syntax is not correct, but it should
--  be clear what it's doing
CREATE TABLE Person
 (
   PersonId   int  not null
     primary key
  ,PartnerId  int  null
     foreign key references Person (PersonId)
 )

```

With this,

* Everyone on the system has a row and a PersonId
* If you have a partner, they are listed in the PartnerId column

Unnormalized data is always bad. Denormalized data, now, that can be beneficial under very specific circumstances. The best advice I ever heard on this subject it to first fully normalize your data, assess performance/goals/objectives, and then carefully denormalize only if it's demonstrably worth the extra overhead.