In layman's terms:

The whole point of relational databases is normalization.

Normalization means separating tables into different tables in order to avoid udpate anomalies and to speed up look ups, reduce redundancy etc.

So your question really is "should a database be normalized?" and the answer is "of course". Obviously there would be exceptions in a per-table basis where you can decide to denormalize for performance's sake.

Normalization dictates that a non-key column should describe the key, the whole key and nothing but the key. So you should avoid things like having the name of the store a product was bought from in the product table.

In the case of the tables you give as examples, I'd put them in a separate table. There's no one-to-one relationship in a relational database, but you can simulate one by adding the correct PK in the child table so that it would be imposible to insert a second spouse to the same employee, or a second payment to an order if that's the business rule. But a more sensible solution would be to add dates to the spouse table so a history of spouses is stored but you could always find the current one, and have multiple payments to an order.

In the other hand, hasSpouse is a calculated field indicated whether or not the spouse-related columns are populated or not. Calculated fields don't comply with normal forms and should only be used in summary tables (which don't abide by normalization rules since they are not transactional).

In layman's terms:

The whole point of relational databases is normalization.

Normalization means separating tables into different tables in order to avoid udpate anomalies and to speed up look ups, reduce redundancy etc.

So your question really is "should a database be normalized?" and the answer is "of course". Obviously there would be exceptions in a per-table basis where you can decide to denormalize for performance's sake.

Normalization dictates that a non-key column should describe the key, the whole key and nothing but the key. So you should avoid things like having the name of the store a product was bought from in the product table.

In the case of the tables you give as examples, I'd put them in a separate table. There's no one-to-one relationship in a relational database, but you can simulate one by adding the correct PK in the child table so that it would be imposible to insert a second spouse to the same employee, or a second payment to an order if that's the business rule. But a more sensible solution would be to add dates to the spouse table so a history of spouses is stored but you could always find the current one, and have multiple payments to an order.

In the other hand, hasSpouse is a calculated field indicating whether or not the spouse-related columns are populated or not. Calculated fields don't comply with normal forms and should only be used in summary tables (which don't abide by normalization rules since they are not transactional). But in this case it's worse because it's not a total summing some other columns but an indicator that could be replaced by simply asking whether a a column is null or not.