I agree with Mike - it's a wiring issue :)
I took over and upgraded a database that had been designed with the
one-table format. At first I bristled 'cuz I thought "No! You've gotta
have a header and details structure."
But for this application, it is working fine. This client repackages
parts - they get a clump of parts in, individually package them and then
ship them to a parts depot. There's one row per clump and that row has
the receipt, shipment and invoicing info. It is a lot simpler and good
to know that others who've responded also use the one-table format. I'm
not shorting out anymore,
Doug
Mike Byerley wrote:
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?
--- RBASE-L
================================================
TO POST A MESSAGE TO ALL MEMBERS:
Send a plain text email to [email protected]
(Don't use any of these words as your Subject:
INTRO, SUBSCRIBE, UNSUBSCRIBE, SEARCH,
REMOVE, SUSPEND, RESUME, DIGEST, RESEND, HELP)
================================================
TO SEE MESSAGE POSTING GUIDELINES:
Send a plain text email to [email protected]
In the message SUBJECT, put just one word: INTRO
================================================
TO UNSUBSCRIBE:
Send a plain text email to [email protected]
In the message SUBJECT, put just one word: UNSUBSCRIBE
================================================
TO SEARCH ARCHIVES:
Send a plain text email to [email protected]
In the message SUBJECT, put just one word: SEARCH-n
(where n is the number of days). In the message body,
place any
text to search for.
================================================
