Maybe I'm wrong, but here it is: history tables are to be used to record changes of some data elements through time. In your example, there are customers who fill order forms and choose one or more items every time. Now, it is possible to write a report and show all items customer ordered in the past. This makes sense to me.
But, what kind of a history element is a date of birth? Everyone has only one date of birth and this information is always valid - 7 years ago, today, next year and in 500 years ...
Perhaps i didn't explain it correctly.
i need to make a DOB field on an existing order form a required field so that this order may be pulled at a later date to record how many people over a certain age ordered the product. I thought it might be wise to create a history table so that running the query for the report would not cause a drain on the application. am I wrong?
If you are building a data warehouse, then it would probably make sense. Otherwise, storing "date of birth" column along with "orders" would be an example of denormalized design. Unless there is a good reason to do so, I'd rather see "date of birth" along with customer data (name, address, ...); orders should contain a foreign key column to join "order" with a customer.