Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!hacgate!ashtate!dbase!tomr
From: tomr@dbase.A-T.COM (Tom Rombouts)
Newsgroups: comp.databases
Subject: Re: What is missing in Paradox 3.5
Message-ID: <1991Apr25.163741.6128@dbase.A-T.COM>
Date: 25 Apr 91 16:37:41 GMT
References: <1991Apr14.054946.24487@NCoast.ORG> <1991Apr15.041214.11383@cica.indiana.edu> <678@lwtua6.sdi.sub.org>
Reply-To: tomr@dbase.UUCP (Tom Rombouts)
Organization: Ashton-Tate
Lines: 33

In article <678@lwtua6.sdi.sub.org> bressler@lwtua6.sdi.sub.org (Stefan Bressler) writes:

     [ Most of discussion of things missing in Paradox 3.5 deleted ]
>
>>-Support for Memo fields  (i know you can use add-ons, but they are cumbersome)
>They are not there but I don't miss them.  The relational data model
>consists of tables and only tables.

I feel that memo fields have nothing to do with the relational model.
To me, they can be viewed as just very large character fields.
Imagine the following hypothetical SQL statement:
  
  CREATE TABLE Coffee
  ( Emp_ID     CHAR(5),
    Lastname   CHAR(20),
    Firstname  CHAR(15),
    Comments   CHAR(65000) );
    
This would effectively create "Comments" as a memo field.  (Of course,
let's hope this would not result in 65000 spaces added to each
record!  That would depend on the particular data engine in use.)
Anyway, I do not see how a very wide character field violates the
relational model in any way.  Perhaps you are thinking of sub-fields,
such as those found in the Pick OS, which clearly violate the 
guidelines of data normalization.

(BTW, yes, I know that memo fields in many products can also
hold binary data.  However, I do believe C.J. Date mentions the
possibility of future data types in his "Introduction to 
Database Systems" 5th Ed.)


Tom Rombouts  Torrance 'Tater  tomr@ashtate.A-T.com