bradbury@oracle.UUCP (Robert Bradbury) (07/13/87)
This is in response to an article about a month and a half ago. (Problems with our news connection prevented an earlier response). In article <711@cod.UUCP>, walker@cod.UUCP (Janet M. Walker) writes: > > We would like sophisticated 4GL capability AND GOOD PERFORMANCE!! So far I > haven't found the "best of all worlds". There are RDBMS products which > have capabilities like binary and unlimited text data types but slower > performance, etc. I would love to hear from vendors and users alike. > Oracle supports a "raw" data type which allows a column up to 65k bytes. Support for raw data in tools like SQL*FORMS (the screen manager) and SQL*PLUS (the basic sql interface) is limited for the basic reason that manipulating a 65K row on a 24x80 screen is ill-defined. Calls are provided in the Host Language Interface to manipulate these large columns. The performance of a DBMS with a column this large (when they are capable of handling them) is limited a great deal by the UNIX file system. (Standard UNIX file systems are not good for reading/writing large chunks of data; BSD file systems are somewhat better but 65K chunks is still pushing things.) Criteria to use in judging whether a database can manipulate large columns of data effectively might include: - Can the database use raw disk partitions? (to avoid the overhead of the UNIX file system) - Can the row of data be stored in an extent of adjacent disk blocks? (to avoid excessive seeking to access individual data blocks) - Is there a cache which can hold several rows of data? (to avoid having to always read the data from the disk) - Is it possible for the data to be read into the cache before it is required by the user (i.e. is there read-ahead)? (to avoid seek/read delays) The performance of a DBMS when dealing with large columns (or rows) is a function of its ability to quickly access and move large chunks of data from the disk to the user and is closely tied to how well the DBMS takes advantage of those features provided by the OS for handling large amounts of data. -- Robert Bradbury Oracle Corporation (206) 364-1442 hplabs!oracle!bradbury
allbery@ncoast.UUCP (Brandon Allbery) (07/22/87)
As quoted from <316@oracle.UUCP> by bradbury@oracle.UUCP (Robert Bradbury): +--------------- | In article <711@cod.UUCP>, walker@cod.UUCP (Janet M. Walker) writes: | > We would like sophisticated 4GL capability AND GOOD PERFORMANCE!! So far I | > haven't found the "best of all worlds". There are RDBMS products which | > have capabilities like binary and unlimited text data types but slower | > performance, etc. I would love to hear from vendors and users alike. | > | The performance of a DBMS with a column this large (when they are | capable of handling them) is limited a great deal by the UNIX file system. | (Standard UNIX file systems are not good for reading/writing large | chunks of data; BSD file systems are somewhat better but 65K chunks | is still pushing things.) +--------------- UNIFY 4.0 provides unlimited-length BINARY and TEXT data types; it also has raw disk partition databases. (However, large data fields promise to have performance slowdowns whether they are on raw disk partitions or not. Don't expect performance in the same region as with 2-byte integers.) I believe ACCELL is available with a UNIFY 4.0 substrate, but I'd ask Unify Corp. about that. I also suspect that UNIFY 4.0 is a different product from UNIFY 3.2, but would like to be proved wrong. (UNIFY 4.0 is out now, I believe, but Plexus is getting ready to ship a UNIFY _3.2_ upgrade. Is Unify slow, or is it Plexus?) -- [Copyright 1987 Brandon S. Allbery, all rights reserved] [Redistribution permitted only if redistribution is subsequently permitted.] Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!cwruecmp!hal,cbosgd}!ncoast!allbery <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>>
michael@wicat.UUCP (Mike Weeks) (08/03/87)
In article <3281@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: ... >I believe ACCELL is available with a UNIFY 4.0 substrate, but I'd ask Unify >Corp. about that. I also suspect that UNIFY 4.0 is a different product from >UNIFY 3.2, but would like to be proved wrong. (UNIFY 4.0 is out now, I >believe, but Plexus is getting ready to ship a UNIFY _3.2_ upgrade. Is Unify >slow, or is it Plexus?) Firstly, ACCELL is available with UNIFY 4.0 or with UNIFY 3.2. I do not have ACCELL myself so I don't know which version's of ACCELL are applicable to each UNIFY version. UNIFY 4.0 is not a different product from 3.2 it is just an enhanced version with the main enhancements being the BINARY and TEXT field types and the ability to customize all of the messages that UNIFY displays by editting a master text file. I don't know anything about Plexus's product line or release procedures but the 'upgrade' may be to 4.0 or they may be getting out the latest version of 3.2 to give them more time to port the 4.0 release. >-- > [Copyright 1987 Brandon S. Allbery, all rights reserved] >Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc Mike Weeks WICAT Systems, Inc.