Re: Any issues with large database views?

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.
Received on Wed Nov 03 1999 - 13:49:04 CST