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? > > > > > > >
