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.
