In the first normal form (1NF) of SQL tables, one shouldn't have repetition of values and columns should have atomic values.
I have a table where I have columns StartDate | EndDate | Duration.
StartDate has value 01/01/2000 and EndDate 03/03/2003, so the duration is 2 dates, 01/01/2000 - 03/03/2003, using the same two values that are in the StartDate and EndDate fields.
Do I get rid of the Duration column completely and assume that one is able to find the info with queries, or is there a way to normalize this to follow the rules without losing any data?
I noticed this problem in the 3NF point when I separated these 3 columns to another table from the other information.
Should this be done way before that?
If StartDate and EndDate are just the dates from Duration, then it functionally determines them, and the two of them together functionally determine it. So normalization (preserving FDs (functional dependencies)) to a high enough normal form will make you separate the three of them into a separate table.
But clearly it is enough to have either {Duration} or {StartDate, EndDate} as a subset of your columns. If you add another of the attributes, it's redundant. Normalization can't help with that, because it only removes redundancies where a table can be replaced by projections of it that join to it.
Generally speaking it is better to store interval end points. The general idea in relational design is to have a column for any part of some thing that you might want to query about separately. Learn about computed/calculated columns if you want to control this kind of redundancy.
PS 1 See this answer re 'atomicity'.
PS 2. Normalization is not done by moving through normal forms to the highest wanted. (Which should be 5NF, then for certain reasons one can denormalize. Normalizing to lower normal forms can exclude good higher-level designs from arising. Find the algorithms for normalizing to 3NF or BCNF.