Per my other response. I created a form just to do the comments in. The
code is a one time deal and the form is called from several different
scenarios where a comment or notation is required.
----- Original Message -----
From: <[email protected]>
To: "RBASE-L Mailing List" <[email protected]>
Sent: Thursday, December 17, 2009 1:08 PM
Subject: [RBASE-L] - Re: Note Data type question
I guess my last post to this question is this:
There is no doubt that to use a second table to hold comments in this
particular situation will require :
A: Significant more programming (and thus error checking) to insert
comment records only if needed etc.
B: When editing records, more checking to see if comment records exist
to display, and then having more programming to add comments at a later
date.
C: When accessing the main records, database traffic will be higher as
checking two tables versus the one will always be more CPU and Disk
intensive than pulling up one record in one table.
D: More loading on the main RX3 index file due to added indexes for
the ID column.
E: Searches on comments will be more difficult.
versus
All the above go away when using a note column on the main table.
Using a very slight increase in disk space with a note column on each
record.
(Disk space will not be an issue in reality here so thus I do not consider
it
a negative)
Is there any REAL value in using the second table (in this particular case)?
If so, what is it? I cannot really think of any but I do not always see the
forest for the trees. How would my database performance, reliability
and programming efficiency improve by using two tables? (Again in this
instance)
The old saying is that a Rolls Royce is a better quality car than a
Volkswagen Bug.
But the new standard of quality now includes VALUE for the intended purpose.
If my only use for the car is to go 4 blocks to the store and back the Bug
is a much
more quality car. It gets better gas mileage, is easier to park and cost
much, much
less. Its replacement cost is a fraction of the Rolls. It therefore is the
better quality car for the job.
Certain aspects in programming can relate to the same scenario! I am
thinking this
is the case here.
Thanks all!
-Bob
Thanks,
-Bob
----- Original Message -----
From: " Emmitt Dove" < emmitt [email protected]>
To: "RBASE-L Mailing List" < rbase -l@ rbase .com>
Sent: Thursday, December 17, 2009 9:41:20 AM GMT -06:00 US/Canada Central
Subject: [RBASE-L] - Re: Note Data type question
How about using a variable memo with an on-exit eep to do the insert if
required?
Emmitt Dove
Manager, Converting Applications Development
Evergreen Packaging, Inc.
emmitt .dove@ everpack .com
(203) 214-5683 m
(203) 643-8022 o
(203) 643-8086 f
emmitt [email protected]
From: rbase -l@ rbase .com [ mailto : rbase -l@ rbase .com] On Behalf Of
karentellef @cs.com
Sent: Thursday, December 17, 2009 9:46 AM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: Note Data type question
Here's my problem with the #4 approach, although granted it is
the most referentially correct and probably the most space efficient.
The problem is: you're on an edit form for the person, and there
is no comment yet in the table for this person. You have a spot
on the form for the comment, and the user thinks he can just tab
or enter thru the form fields and go right into the comment field and
start typing. But he can't because the comment isn't there. So you
have to add the row first.
What is the best way of doing this? You can cheat by adding a blank
row before you bring the form up, and deleting the row after you exit
if they don't enter, but this fills up the table needlessly. Do you put
some kind of automatic insert using an eep if they leave the first
table? Again, have to insert and possibly delete.... That's the only
reason I usually don't use this type of structure myself.
Karen
Bob,
Your options are:
1) Include a TEXT datatype on every row. This eats up a lot of space without
need.
2) Include a NOTE datatype on every row. This is less demanding of space,
but carries the issue of the relocation of rows when the note grows beyond a
certain point.
3) Include a VARCHAR datatype on every row. This is less demanding of space
in file 2, and avoids the row relocation issue with NOTE types, but will
consume space in file 4 for every row.
4) The linked table with the datatype of your choice.
Personally, I’d opt for 4. We use that approach for comments on a bill of
lading, for example, with great success. You only take up space when you
require, and you can use whatever datatype you wish.
