davidm@uunet.UU.NET (David S. Masterson) (02/02/90)
In article <7388@tank.uchicago.edu> monty@delphi.uchicago.edu (Monty Mullig) writes:
let's define some terms.
Ok, as long as we define ALL the terms...
to my mind, a variable length field is one in which no fixed maximum
or minimum is specified by the user.
Fine, but what is the purpose of such a field? Where would you make use of it
and why? What problems are incurred with being "forced" to specify a maximum?
now, the system might place some restrictions on the size of the
field, such as it must be between 0 and 65,534 bytes long, but the
user doesn't specify a limit.
How would it differ from a LONG VARCHAR field (DEC RDB terminology, I think)
in which the upper limit isn't specified, but its certainly known (65536)?
--
===================================================================
David Masterson Consilium, Inc.
uunet!cimshop!davidm Mt. View, CA 94043
===================================================================
"If someone thinks they know what I said, then I didn't say it!"nico@unify.uucp (Nico Nierenberg) (02/03/90)
In article <7388@tank.uchicago.edu> monty@delphi.UUCP (Monty Mullig) writes: >let's define some terms. > >to my mind, a variable length field is one in which no fixed maximum >or minimum is specified by the user. its declaration might be >something like: > > fieldname varlen; I don't really think that is important whether or not a maximum length must be declared. After all the user could simply declare this length to be the maximum acceptable field length for this data type. This would seem to be purely a semantic issue. If Oracle has a maximum size it could take the above syntax and convert it to a declaration of a field of the maximum length. > >now, the system might place some restrictions on the size of the >field, such as it must be between 0 and 65,534 bytes long, but the >user doesn't specify a limit. perhaps a better name for this kind of >field would be an "arbitrary length field". is this kind of field >available with oracle ? > Strangely enough I think that this is a bigger issue since it is the physical restriction on the capability of the data type. If the system restricts it to 65,534 bytes and the user needs a 2MB image then there is a problem. By the way Unify doesn't require the size to be specified in advance just in case anyone thinks I'm biased by our design decisions. -- --------------------------------------------------------------------- Nicolas Nierenberg "No matter where you go, Unify Corp. there you are." nico@unify
tim@okra.sybase.com (Tim Wood) (02/03/90)
In article <7388@tank.uchicago.edu> monty@delphi.UUCP (Monty Mullig) writes: >to my mind, a variable length field is one in which no fixed maximum >or minimum is specified by the user. its declaration might be >something like: > fieldname varlen; >now, the system might place some restrictions on the size of the >field, such as it must be between 0 and 65,534 bytes long, but the >user doesn't specify a limit. perhaps a better name for this kind of >field would be an "arbitrary length field".... [ was this the intent >of the original poster? {Hi, Jon} ] > >...[ variable-length and arbitrary-length fields ] >both possess a user specified field and thus cannot support arbitrary >lengths longer than the maximum AFTER they have been defined. > Then what's the advantage of arbitrary length, unless it allows a higher system maximum? Actually, it has a subset of the variable-length features. Since both are subject to a system-defined maximum, why shouldn't the database designer be able to bound the size of the values? That cannot be done with arbitrary length (except by defining a higher-level semantic rule). If the db designer doesn't care how big the values get, s/he can just define the column to be var{char,binary} of the system maximum length. Of course, only the amount of data in each value + some epsilon for overhead will be physically stored. I can't see any difference between variable-length and logically stripping off trailing blanks, unless "variable-length" allows sparse values, i.e. "chunks" of bytes strung together with interspersing spaces where these spaces are not physically stored. -TW Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500 tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim This message is solely my personal opinion. It is not a representation of Sybase, Inc. OK.
davis@hplabsz.HPL.HP.COM (Jim Davis) (02/03/90)
The obligatory synopsis may be found below my remarks.
Michael Friedman <mfriedma@oracle.UUCP> asked:
mf> Mind telling me what I could do with variable length
mf> columns that I can't do with regular Oracle columns?
The major capability missing is the ability to program with
assurance that a datum from one column could be stored into another.
If the only limit is the system limit and it is imposed without the
necessity of common agreement by all concerned on an explicit value
then the resulting "code" is often far better.
As an example of this consider code to handle user ASCII input.
Some people (and code) consider 160 characters as a reasonable maximum
line length for user input. Some take 1024 or 4096 characters as a
single line. The better ones will handle millions of bytes.
Note that I do consider *allowing* user specified maximum column
lengths to be advantagous, it is requiring them that concerns me.
-- Jim Davis
(Of course I speak for myself and not my company.)
-----------------------------------------------------------------
Synopsis: "or you can't tell the players without a program card"
Young-Mee Yang <yang@presto.IG.COM> asked:
ymy> How about others, Oracle, Sybase, Ingres?
ymy> Do they allow variable record length?
David E. Anderson <danderso@oracle.com> answered:
dea> Subject: Re: variable record length
dea> Summary: Oracle supports variable length records
dea> The subject says it all... Always Had It, Always Will
Jonathan Krueger <jkrueger@dtic.dla.mil> wrote:
jk> Oh, good. Please show me your SQL statement that creates a table
jk> with a text column without a specified size.
David S. Masterson <davidm@cimshop.UUCP> suggested:
dsm> create table testing (
dsm> col1 varchar(80)
dsm> );
dsm> The key is in knowing that the "80" is a specified MAXIMUM size. ;-)
Dave Simson <dsimson@oracle.com> wrote:
ds> The length in the SQL statement is the maximum length. Oracle *stores*
ds> all character columns as variable length (ie not taking up more space
ds> than needed for the data in question) so all character columns are in
ds> effect variable length.
Jonathan Krueger retorted:
jk 2> Thanks for the clarification. As we see, Oracle has never had it, and
jk 2> as far as we know, never will.
jk 2> "It" is variable record length, not trailing whitespace
jk 2> compression. The original article never asked about the latter,
jk 2> the question was simply which databases support the former.
jk 2> If you must put your marketing claims on the net, please limit
jk 2> yourself to accurate information that answers the question put.
Michael Friedman <mfriedma@oracle.UUCP> asks:
mf> I'm just an applications developer. I'm not a marketer and I'm not a
mf> kernel developer, so I'm really not interested in the fancy names or
mf> the theoretical schtick. I'm interested in what I can produce for
mf> customers.
mf> Mind telling me what I could do with variable length
mf> columns that I can't do with regular Oracle columns?pavlov@canisius.UUCP (Greg Pavlov) (02/04/90)
In article <1990Jan31.040651.20590@oracle.com>, mfriedma@oracle.com (Michael Friedman) writes: > > }}The length in the SQL statement is the maximum length. Oracle *stores* > }}all character columns as variable length (ie not taking up more space > }}than needed for the data in question) so all character columns are in > }}effect variable length. > > Mind telling me what I could do with variable length columns that I > can't do with regular Oracle columns? > Depending on your database, save a lot of disk space. For instance, our databases are composed almost exclusively of 1-4 -byte data items. When we tried loading one of these into Oracle, the database ballooned in size: there is a lot of overhead supporting this automatic variable length "feature". Consequently, when projecting costs for Oracle vs. other dbms's, we had to haul out our favorite vendor's disk catalogue...... (well, to be honest, we didn't choose Oracle for a lot of other reasons as well). greg pavlov, fstrf, amherst, ny
pavlov@canisius.UUCP (Greg Pavlov) (02/04/90)
In article <DSIMSON.90Jan30170332@arthur.oracle.com>, dsimson@oracle.com (David Simson) writes: > ...(talking about a record with a declared 60-byte filed in an Oracle table) ..................................... If you insert a record > into this table where the column has a value of length 30, only 30 > bytes (assuming we're not talking multi-byte character sets) plus an > overhead of 1 byte for the length is stored. > Well, the overhead is actually greater than one byte. Since the resulting RECORD is variable in length as well, that has to be delineated as well. greg pavlov, fstrf, amherst, ny
jkrueger@dev.dtic.dla.mil (Jonathan Krueger) (02/05/90)
mfriedma@oracle.com (Michael Friedman) writes: >Mind telling me what I could do with variable length columns that I >can't do with regular Oracle columns? Write code that need not be aware of length limits for data values. Said code implements applications that can insert and update without being able to overflow column limits. As a practical matter, if maxima are large it doesn't make any difference. As a practical matter, Oracle's maxima are not large. -- Jon -- Jonathan Krueger jkrueger.dtic.dla.mil uunet!dgis!jkrueger Isn't it interesting that the first thing you do with your color bitmapped window system on a network is emulate an ASR33?
craig@unify.uucp (Craig Isaacs) (02/06/90)
In article <1990Jan31.040651.20590@oracle.com> you write: >I'm just an applications developer. I'm not a marketer and I'm not a >kernel developer, so I'm really not interested in the fancy names or >the theoretical schtick. I'm interested in what I can produce for >customers. > >Mind telling me what I could do with variable length columns that I >can't do with regular Oracle columns? > With variable width columns (UNIFY's "text" and "binary" field types) customers can store images, documents, etc... as part of their RDBMS so they can integrate their RDBMS applications with other technologies. For example, an human resource application could store not only the age, ss #, address, etc. of the employee, but also an image of the employee captured by video camera (or scanned photo). Regards, -- ---------------------------------------------------------------------------- Craig Isaacs internet: craig@unify.UUCP Unify Corporation ...!{csusac,pyramid}!unify!craig
corpspt@oracle.com ((Owner) Mary Winslow) (02/06/90)
In article <4qx80zz@unify.uucp> craig@unify.UUCP (Craig Isaacs) writes: >In article <1990Jan31.040651.20590@oracle.com> you write: >>I'm just an applications developer. I'm not a marketer and I'm not a >>kernel developer, so I'm really not interested in the fancy names or >>the theoretical schtick. I'm interested in what I can produce for >>customers. >> >>Mind telling me what I could do with variable length columns that I >>can't do with regular Oracle columns? >> >With variable width columns (UNIFY's "text" and "binary" field types) >customers can store images, documents, etc... as part of their >RDBMS so they can integrate their RDBMS applications with other >technologies. > >For example, an human resource application could store not only the age, >ss #, address, etc. of the employee, but also an image of the employee >captured by video camera (or scanned photo). > >Regards, > >-- > >---------------------------------------------------------------------------- >Craig Isaacs internet: craig@unify.UUCP >Unify Corporation ...!{csusac,pyramid}!unify!craig The Oracle LONG (implies automatic character translation will occur on transfer between ASCII and EBCIDIC machines) and LONG RAW (no translation is performed) data types can hold values up to 64k in length. An increase in these limits is under consideration. The VARCHAR and CHAR datatypes are limited to a maximum of 255 characters. An increase in this limit is under consideration. Notes: These are all variable length datatypes. The number of datafile bytes occupied by the data varies dynamically as the value is updated. The size in the column definition determines the maximum length the user allows for a value; it does not imply pre-allocation of bytes. The maximum length established in the declaration can be changed later using the ALTER TABLE MODIFY command. I have submitted an enhancement request to allow declarations without a size, which would imply the inherent maximum allowed for that datatype. (In case jkrueger@dgis.dtic.dla.mil (Jon) ever has to use Oracle :-)) Craig, I think we are describing similar functionality in our products... From what tim@okra.sybase.com says, I think Sybase has the same, as does Informix and (I think) Ingres. -David "Data, that's enough!" - Jean Luc Picard
jkrueger@dev.dtic.dla.mil (Jonathan Krueger) (02/07/90)
craig@unify.uucp (Craig Isaacs) writes: >With variable width columns (UNIFY's "text" and "binary" field types) >customers can store images, documents, etc... as part of their >RDBMS so they can integrate their RDBMS applications with other >technologies. Oh, good. Please tell us how UNIFY selects on columns of this type. For instance, take the document idea, say given a table like +-----+ | emp | name hiredate resume +-----+---------+-------------------------------------------------+ | Stevans | 20 Sept 1989 | 1975 to 1978: wrote database ... | +---------+-------------------------------------------------+ would the select syntax look like select name from emp where fulltext(resume, "UNIX") = 1 Or what would it look like? Also, please explain how indexing and storage structures would prevent exhaustive table scans. This will help us understand how UNIFY customers can integrate their RDBMS applications with other technologies. -- Jon -- Jonathan Krueger jkrueger.dtic.dla.mil uunet!dgis!jkrueger Isn't it interesting that the first thing you do with your color bitmapped window system on a network is emulate an ASR33?
jkrueger@dev.dtic.dla.mil (Jonathan Krueger) (02/07/90)
corpspt@oracle.com ((Owner) Mary Winslow) writes: >The Oracle LONG ... can hold values up to 64k in length. Last I checked, Oracle LONGs could not be selected on, pattern matched, indexed, or sorted on. Is this still the case? If so, this isn't a data type: it's persistent shared storage. If not, please show how Oracle would form the followinq query: Given a table like (deja vu, anyone?) +-----+ | emp | name hiredate resume +-----+---------+-------------------------------------------------+ | Stevans | 20 Sept 1989 | 1975 to 1978: wrote database ... | +---------+-------------------------------------------------+ would the select syntax look like select name from emp where fulltext(resume, "UNIX") = 1 Or what would it look like? Also, please explain how indexing and storage structures would prevent exhaustive table scans. This will help us understand how Oracle customers can use their LONG and LONG RAW data types. -- Jon -- Jonathan Krueger jkrueger.dtic.dla.mil uunet!dgis!jkrueger Isn't it interesting that the first thing you do with your color bitmapped window system on a network is emulate an ASR33? > I have submitted an enhancement request to allow declarations without a > size, which would imply the inherent maximum allowed for that datatype. > (In case jkrueger@dgis.dtic.dla.mil (Jon) ever has to use Oracle :-)) I would be happy to use Oracle for tasks it's suited to. Your enhancement adds nothing to Oracle's suitability for highly textual applications. It's trivial for the database designer to declare all Oracle colums to the maximum size allowed. That's not variable length columns, nor support for same, and therefore its automation is not a useful addition to your product. -- Jon -- Jonathan Krueger jkrueger.dtic.dla.mil uunet!dgis!jkrueger Isn't it interesting that the first thing you do with your color bitmapped window system on a network is emulate an ASR33?