I think you just feel it's odd because you're doing it differently than you
have been wired to do so far.... It'll pass. ;-)
----- Original Message -----
From: "Javier Valencia" <[email protected]>
To: "RBASE-L Mailing List" <[email protected]>
Sent: Thursday, December 16, 2010 8:17 PM
Subject: [RBASE-L] - Re: One table vs. two tables.
Thanks for the feedback Mike and Albert,
I tend to agree with Mike; the simplicity of one table is certainly
appealing. I have been moving in that direction lately and I keep thinking
I
am doing something that I am not supposed to do, but so far...no problems.
Javier
Javier Valencia, PE
913-829-0888 Office
913-915-3137 Cell
913-649-2904 Fax
[email protected]
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Mike
Byerley
Sent: Thursday, December 16, 2010 4:48 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: One table vs. two tables.
Javier,
When I changed my old internal system to the 7.x and later, one of the
things I changed in Accts Payable was droping the Master/Detail
relationship
to a single table with TransID as the PK. It has caused me zero
difficulty
and I never have to approach the data from the Master/Detail when doing
reports. I think it is simpler.
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?
