Re: Any issues with large database views?

Hi, Steve,

     Thank you for your post. I considered some time ago the design you outline below but dismissed it because I did not think that we would ever hit the 1000 field ceiling (for Oracle 8 tables and views). Moreover, basing the application on a cursor select rather than a table or view is a slightly more complicated programming task. However, now that I realize exactly how many fields could be present, I plan to reconsider your method and subject it to further analysis. The database design would certainly be better the way you describe. Thanks again for bringing this option to my attention!

Cary

In article <7vq3lr$a30$1_at_plo.sierra.com>,   "Steve McDaniels" <steve.mcdaniels_at_sierra.com> wrote:
> sounds like you should be using a table like this:
>
> create table cdr
> (
> mfg_code varchar(...),
> field_type varchar(...),
> field_value varchar(...)
> )
>
> In our organization, we refer to this as name/value pairs; our
customers,
> when installing our software,
> run a setup routine which encourages them to "register" with us.
Since we
> need to be able to handle
> cd's burned, oh, say, a year ago, even though we've changed
the "content" of
> the registration, we can
> still handle these "old" formats (based on mfg_code, or in our
instance,
> version_code)
>
> A simple procedure with cursor can denormalize this at some later
point in
> time
> (i.e.,
> select mfg_code,
> decode(field_type,1,field_value) F1,
> decode(field_type,2,field_value) F2,
> decode(field_type,3,field_value) F3, etc.
>
> <clapoint149_at_my-deja.com> wrote in message
> news:7vn0am$217$1_at_nnrp1.deja.com...
> > Hi, Randy,
> >
> > The data we are dealing with are telephone call detail records
> > (CDR's), which contain between 30 and 100 fields. To complicate
> > matters, we have to store records produced by telephone switches
from
> > several different manufacturers and be able to access these CDR's
as a
> > single entity (for application purposes). While there is some
overlap
> > among the various CDR formats, there are also many fields unique to
all
> > of a given manufacturer's CDR formats or even to a given
manufacturer's
> > individual CDR formats. For this reason, the number of fields will
be
> > fairly large. Since we are developing our storage design from
scratch,
> > we want to take the time to do it properly and avoid any problems
> > associated with expanding our storage structure as we
support/integrate
> > new CDR formats (which will certainly happen).
> >
> > In article <381E0B59.3FCCD596_at_cais.com>,
> > randy_at_euclidsys.com wrote:
> > > I am very curious.
> > >
> > > What kind of data needs this many fields?
> > >
> > > randy
> > >
> > > clapoint149_at_my-deja.com wrote:
> > > >
> > > > Hello,
> > > >
> > > > I have the need to store records which will consist of
several
> > > > hundred but < 1000 fields. My current understanding is that for
> > Oracle
> > > > 8 and above the table column limit is 1000 and for previous
> > versions of
> > > > Oracle's database server the table column limit is 254.
However, I
> > > > have heard that even with the newer versions of the database
server
> > > > there are still issues with creating/using tables with more
than 254
> > > > columns. I personally do not know what these issues might be,
nor
> > do I
> > > > know if they actually translate as problems per se. What I am
> > > > wondering, though, is if these issues (whatever they are) also
> > apply to
> > > > large views (with several hundred columns) that join medium-
sized
> > > > tables (each with at most about 100 columns), which is how I
prefer
> > to
> > > > store/access my large records. My guess is that large views are
> > immune
> > > > since any table problems most likely stem from physical storage
> > design,
> > > > but I do not know for sure. Could someone shed some light on
any
> > > > issues related to large database tables and views? Thanks.
> > > >
> > > > Cary
> > > >
> > > > Sent via Deja.com http://www.deja.com/
> > > > Before you buy.
> > >
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Thu Nov 04 1999 - 09:00:57 CST