Javier, I would suggest the two table option. The reads are quicker on
the WHERE clause (although with modern computers you might not even
notice) and also changes to the detail section structure are easier to do.
My C$0.02.
Albert
On 16/12/2010 12:40 PM, Javier Valencia wrote:
I have an application where an equipment evaluation is generated
periodically for app. 700 pieces of equipment. I can set up the data
structure as on or two tables.
One table approach:
Table Evaluation
EvalID
EvalDesc
EvalDate
Other data columns
========================
Two table approach:
Table EvaluationDesc
EvalID
EvalDesc
EvalDate
EvaluationData
EvalID
Other data columns
========================
The two table approach does conform to the “no duplication of data”
principle but it requires a two table form and reports would need to
use either a view or a sub-report and more maintenance. The one table
approach does duplicate data, but maintenance is much simpler; i.e.
one table forms and reports, backups, data transfer.
I am inclined to go with the one table approach as the increase in
storage (no longer an issue) is more than offset by the additional
effort needed to work with two tables. Any thoughts?
