However, if the appropriate attributes were added to a "1_TABLE_APPROACH", such an implementation would/could support all required uses, shouldn't it?
Later, Steve in Memphis ----- Original Message ----- From: "Alastair Burr" <[EMAIL PROTECTED]> To: "RBASE-L Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, September 17, 2003 12:11 PM Subject: [RBASE-L] - Re: Note Fields > As Albert Berry noted, there is no need to have only one note table in a > database. I think I would prefer not to have only one - except where only > one type of note is being stored, of course. > > In my case, I have notes for comments on artists and tracks and items and > people (writers, publishers, musicians, labels, etc) which all have separate > note tables. This is so that if there is a problem, hopefully, only one > table needs repairing. > > That said, touch wood, I've never had a problem but there's always a first > time... > > Regards, > Alastair. > > ----- Original Message ----- > From: "Fogelson, Steve" <[EMAIL PROTECTED]> > To: "RBASE-L Mailing List" <[EMAIL PROTECTED]> > Sent: Wednesday, September 17, 2003 5:09 PM > Subject: [RBASE-L] - Note Fields > > > > A while back I had asked about Text vs. Note fields. > > > > A few responses indicated that they keep all "note"s in a separate table. > > Evidently problems with broken pointers. > > > > I assume you design your DBs with a table for ALL notes. And all the other > > tables contain Note_ID fields where appropriate, that point to that note > in > > the note table. Then use a view to read a row including the note. > > > > Are these assumptions correct? > > > > Could someone elaborate on this design and problems with broken pointers. > > How is this design strategy easier to fix broken pointers? > > > > Thanks > > > > Steve Fogelson > > Internet Commerce Solutions > > >
