Is it "bad design" to have 2 related tables, each one having a column (named differently) whose value will always be the same in both? Imagine that I have the following database structure

TableUser (
   userId integer,
   weeksToLive integer
)

TableCalendar (
   calendarId integer,
   numberOfCells integer,
   userId integer REFERENCES TableUser
)


The point is this will always be the case:

TableCalendar.numberOfCells = TableCalendar.weeksToLive


So I'm wondering if it is harmful or something to have two columns which will always contain the same value, so that the same value can be obtained using different select statements.
In general, keeping redundant data in a relational database is considered a bad design. There are several problems associated with redundant data:


There is the danger that application errors or manual interventions introduce inconsistencies into the database by modifying only one copy of the redundant information. This is the main problem.
Performance is sapped by having to write more data than necessary, or by constraints or other measure that are to ensure consistency of the copies.
You waste storage space. That is usually a minor concern.


These things are reflected on a theoretical level in the concept of database normalization, which establishes rules that aim at avoiding data redundancy (among other things).

So from a performance point of view, data redundancy makes data modifications slower, but it can speed up queries, because the data can be fetched from several locations, which may make some queries simpler and faster.

Sometimes that is a good enough reason to introduce data redundancy (&ldquo;denormalization&rdquo;), but you should only do that if it is necessary for performance reasons, and the advantages outweigh the disadvantages listed above.