my question would be can age be considered a composite attribute? Because name is a composite attribute and it can be divided into first name, middle name and last name. And therefore can age be a composite attribute since you can divide it into years, months and then days?

  • 6
    You can divide a last name into letters, but that doesn't make it a composite attribute. Would you ever want to know only the "months" component of someone's age? Dec 12, 2016 at 11:15
  • 11
    So you store your age (say 20 years, 10 months, 5 days) in the DB and now you're always that old?
    – user188153
    Dec 12, 2016 at 11:23
  • 1
    @Blrfl Getting philosophic? Age is always dynamic. "Age at" is static, though pointless as you can calculate it from the birthday (which is definitely static).
    – user188153
    Dec 12, 2016 at 13:06
  • 9
    Please read Falsehoods Programmers Believe About Names as you seem to be believing some falsehoods about names. Dec 12, 2016 at 14:28
  • 12
    Please don't store age in the database... Store Birth Date sure, but not age!
    – Milney
    Dec 12, 2016 at 15:11

4 Answers 4


Can age be a composite attribute? No. age is a function of birthdate and now.

age = now - birthdate

So, what about birthdate? Can it be a composite attribute?

Yes, it can, but it only makes sense to store dates as a composite in data warehousing situations.

Often, when warehousing data, you would store year, month, and day as separate things to make it easier to write queries such as

How many people were born in March?


Of all the people born in 1982, how many have blue eyes. How does that compare to April 1992?

You'd also likely have a table that maps dates to quarters, so you could ask things like:

How do birth rates compare between Q1 and Q2 over the last decade?

These are contrived examples, but hopefully illustrate the point. I'd recommend doing some research on "star schema" databases and "slowly changing metrics".

  • The questions "Can age be a composite attribute" and "Can age be stored as a composite" are completely unrelated, until one starts to mutilate her logical data model to better fit her physical data model for performance purposes.
    – Joker_vD
    Dec 12, 2016 at 16:10
  • 3
    @Joker_vD as always, it depends. Is this for a transactional db underneath an application? Then no, don't do this. Is it warehoused for reporting where no general purpose language will consume the data? Ok, yup. Optimize the storage for that.
    – RubberDuck
    Dec 12, 2016 at 16:12
  • 1
    Furthermore in Korea, when you're born you have 1 years already so the function is different ;D
    – Walfrat
    Dec 13, 2016 at 13:50
  • @Walfrat sigh internationalization...
    – RubberDuck
    Dec 18, 2016 at 14:24

Yes, you can store Age as a composite of year, month, date, hour, minute, second in the database if you want to.

However this is probably not a good idea in most cases, because Age can be derived from other values that are usually preferable to have stored in the database. The main reason is that it is better to store birthdate rather than Age; because birthdate is constant but Age depends on the current time. As soon as you save your Age, (unless it is some kind of value for "Age at a certain time", rather than dynamic age) then it will be increasingly incorrect over time.

Storing data that can be derived from other pieces of data is also a violation of some levels of Normal Form and can lead to issues such as data redundancy and inconsistency.


In layman's terms:

  • Usually age is not stored since it's such a volatile attribute. It changes by the second. So storing it is an universally recognized bad idea.

  • Usually date of birth is stored instead.

  • What you want is a representational requirement that can be easily calculated at presentation time or in a database view by writing a rather trivial function -- in the case there isn't already a built in format function in the RDBMS or the development language that already does that.

In conclusion: yes, you could do that, but that would be strongly inadvisable.


store the birthdate and calculate the age everytime

Like the others said there is no meaning in storing age directly.

it is not efficient to decompose or normalize too much

Although you can represent dates as 3 column day, month an year this is not efficient at all.

There is only performance advantage in splitting fields that can be indexed. And indexing the any combinations of day, month and year is way less efficient than index the date field instead.

For administrative software systems the performance bottleneck is usually data transfer not processing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.