In my one table setup, the txtMSG field is short, 50 chars and can contain
the actual message or a TransMsgID text value that links to a TransNote
table with a Note datatype for instances when there just has to be a lengthy
description of the transaction. Note datatype safely relagated to a linked
table.
----- Original Message -----
From: "James Bentley" <[email protected]>
To: "RBASE-L Mailing List" <[email protected]>
Sent: Friday, December 17, 2010 6:05 PM
Subject: [RBASE-L] - Re: One table vs. two tables.
Javier,
In my opinion one vs. two tables depends on whether the description field is
a NOTE data type. If it is a NOTE datatype then go with a two table
approach as recovery of a table with NOTE is more complex that if the table
is just other data types. Otherwise one table is ok.
The two table approach with a NOTE data type make recovery the table easier
since changes to the note column could cause relocation of the entire row.
As to reports, labels I always use a view and a LEFT OUTER JOIN will make
reports easier to develop.
Jim Bentley
American Celiac Society
[email protected]
tel: 1-504-737-3293
--- On Thu, 12/16/10, Javier Valencia <[email protected]> wrote:
From: Javier Valencia <[email protected]>
Subject: [RBASE-L] - Re: One table vs. two tables.
To: "RBASE-L Mailing List" <[email protected]>
Date: Thursday, December 16, 2010, 7:17 PM
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?
>
>
