l. If you are ever in Dallas, look me up.
Agreed ;-) If you'll be in Washington DC, let me know!
> > -Original Message-
> > From: Michael Netrusov [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, March 23, 2001 4:31 PM
> > To: Multiple recipients of list ORACLE-L
>
; Sent: Friday, March 23, 2001 4:31 PM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: Single Code Table or Separate Code tables dilemma
>
>
>
> > > Well, in the case of 100 tables you are still hunting all the
> > > code looking for pieces which are rele
A 'single' code table is something that Gurry and
Corrigan favor as a performance enhancement.
I have not tried it myself; I feel about it as you
do. If I were trying to wring every last bit of
performance out of an app though, I would probably
give it a shot.
Jared
On Fri, 23 Mar 2001, Jacq
STAR Queries would perform better with multiple smaller tables (known as
Dimension Tables). STAR QUERIES are designed specifically for Decision
Support Systems where multiple cartesian products are created on the smaller
(dimension) tables and then joined with the LARGE fact table.
Sam
-Or
Title: RE: Single Code Table or Separate Code tables dilemma
> -Original Message-
> From: Mandar Ghosalkar [mailto:[EMAIL PROTECTED]]
>
> i dont disagree with u. even i dont like the below mentioned
> implementations. i always prefer seperate tables. btw "lot
i dont disagree with u. even i dont like the below mentioned
implementations. i always prefer seperate tables. btw "lot of rows" is very
subjective.
i dont know what u mean by "I have to have a table that contains every
possible combination of SPLT and TYPE. ".
anyways, its a common practice t
Title: RE: Single Code Table or Separate Code tables dilemma
I hate to be picky, but I don't like either of the solutions proposed below. For the first solution, that means that I would have to have the repeating values 'SPLT' and 'TYPE' in every row of the DOCTOR tab
CREATE TABLE I_DONT_LIKE_MASTER
( CODE_TYPE VARCHAR2(4) NOT NULL,
CODE_VALUE VARCHAR2(3) NOT NULL,
CODE_DESC VARCHAR2(20) ,
PRIMARY KEY (CODE_TYPE, CODE_VALUE) )
SPLTN SDFLJDSL
SPLTFP SDFSDKFDS
SPLTOBG SFLSDJFSD
TYPEMD SDFLSDFSDF
TYPEFP SDFJDSFJ
TYPE
Title: RE: Single Code Table or Separate Code tables dilemma
I'm still not quite sure I understand the "single code table" business. Let me give an example (taken from a live example at one of my previous jobs).
I have a table called DOCTOR that has two fields - SPECIALT
> > Well, in the case of 100 tables you are still hunting all the
> > code looking for pieces which are relevant to that changed table.
> > Depends on your code. I prefer to encapsulate mine, so
> > reference to a table is enclosed in its own package.
>
> My point is that I can use grep to search
I've found so many bugs in code caused by developers forgetting to add "AND
code_type = 'SOME_VALUE'" to there WHERE clauses when multi-purpose code
tables are used.
Kevin Toepke
-
The information in this electronic mail message is Cendant Confidential
and may be lega
Snipped text
> > The DBA work on that is easy, but then the developers go
> hunting in all the
> > existing program code that hits the code table (haystack)
> to find all the
> > places where that program code is actually using the code
> in question
> > (needle).
>
> Well, in the case of 100
- Original Message -
> Preface: I am a developer!
>
> If the DBA wants to have 1 tables, no skin off my nose. A generic
> maintenance form and LOV form for a set of tables all with the same format
> is not that huge a task.
>
> The best developer argument AGAINST a centralized code t
At one of the Oraccle Applications User meetings, Oracle displayed the new table
layout for the 11i version. It basically was one table with a lot of columns for the
application that was talked about. I asked about the normalization of the data and the
reply was in the form: it will take more d
s of list ORACLE-L
>
>
>
> > -Original Message-
> > From: Michael Netrusov [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, March 22, 2001 4:23 PM
> > To: Multiple recipients of list ORACLE-L
> > Subject: Re: Single Code Table or Separate Code tables di
> > From: Steve Orr [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, March 22, 2001 5:55 PM
> > To: Multiple recipients of list ORACLE-L
> > Subject: RE: Single Code Table or Separate Code tables dilemma
> >
> >
> > Regarding "lookup" or validation
ok.
lookup_id varchar2(20) pk
lookup_type_id varchar2(20) pk, fk
description varchar2(255)
I use the first approach when lookup_type has several invariant values.
One index with an extra level of index block causes a performance hit only when you
are running your DB
> > What's wrong with a composite foreign key constaint? Works
> > for me all the time..
>
> As a duhveloper wont u like to pass one argument to a procedure rather than
> two?
I don't care - I am using the wonderful copy-paste.
> > > > granular control over the individual code table
> > > You DO
Nice, but this construct violates Second Normal Form. I only denormalize for
compelling reasons, like for performance reasons, and I don't see how performance is
enhanced by jamming all this stuff into one big table. You may end up with an index
that has an extra level of index blocks, which
Mandar
Tell them that (if they are really lazy) you can build them a function that
returns ref cursor with Code, description columns and they pass in the
domain/context they want - same for the inserts - so you can get rid of
their comments. To be sincere, I use combination - separate look-up ta
at last i convinced my duhvelopers to go for individual tables.
> -Original Message-
> From: Steve Orr [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 22, 2001 5:55 PM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Single Code Table or Separate Code
Preface: I am a developer!
If the DBA wants to have 1 tables, no skin off my nose. A generic
maintenance form and LOV form for a set of tables all with the same format
is not that huge a task.
The best developer argument AGAINST a centralized code table is that
eventually someone will reque
> -Original Message-
> From: Michael Netrusov [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 22, 2001 4:23 PM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: Single Code Table or Separate Code tables dilemma
>
>
>
>
> > > Referenti
> > Referential integrity is still present if you create Master lookup table
> > with type attribute
> This requires a "composite referential integrity constraint" such as:
> alter table tname
> add constraint fk_whatever
> foreign key (extra_column_for_code_table_key,
>
> Referential integrity is still present if you create Master lookup table
> with type attribute
This requires a "composite referential integrity constraint" such as:
alter table tname
add constraint fk_whatever
foreign key (extra_column_for_code_table_key,
c
Referential integrity is still present if you create Master lookup table with type
attribute:
lookup_id varchar2(20) pk
lookup_type varchar2(20) pk
description varchar2(255)
> 1. specific attributes for a particular code type is logically and physically
>separated from o
Code tables... been there done that (with PowerBuilder/Oracle) and I don't
like it. Here's why...
Large apps may consist of 100's or 1000's of lookup tables so duhvelopers
like the "master code table" idea because they only have to build one front
end for maintaining all the "lookup" values. But
Check "The Data Warehouse Lifecycle Toolkit" by Ralph Kimball for the
definitive answer.
-Daniel
-Original Message-
Sent: Wednesday, March 21, 2001 7:32 PM
To: Oracledba (E-mail); ORACLE-L (E-mail)
Guys,
We r working on a Datawarehouse solution.
Our Duhvelopers want to merge all code
29 matches
Mail list logo
