No, I'm not being facetious, I'm being honest (welcome to my world)... that
is the exact statement that was given in the meeting... that I was not
invited to, but my boss was.  And the statement came with preening and
posturing, because it was the model that the author of the statement came up
with.  My input... I just have to make it work, my input is usually
irrelevant, I'm JUST the DBA.  The phrase "April, Sit down and shut up"
usually crops up when I try to make a point in our "brainstorming" meetings.


BENCHMARKS?  Yeah... okay.  This "POC" was done on the AIX-RS6000 equivalent
of a 486.  ONE cpu, and I had to get REAL creative just to get the DASD to
give them room to make it RUN.  Benchmarks come later... when I finally can
get them on a test box.  I will get benchmarks in the big real POC that
starts in April... probably.  We were not to keep statistics on the load
time, that was irrelevant... just get data in it.  The only "important"
statistics were on query times.  The way I have it figured it was probably
closer to blocks per row in this DB Instance than rows to blocks (4k blocks,
on average 15(bytes)*650(columns per row average containing data)).  Most
queries that we believe will run will bring back, at most, 50 of those
columns... most not that many.  I gave them statistics on IF we could get it
to ever load we would end up with a table with 560 gig per year growth and
indexes on that table of roughly a terabyte growth per year if they indexed
it the way they wanted to... AND it would ever load or the indexes would
ever build... but I didn't have FACTS to support it, only extrapolations on
existing data.  Until I could prove it wouldn't work, we would go on the
premise that it would.

The "TEAM" knows reality... but the "LEADER" doesn't seem to feel that
reality should play a part.

Sorry... yesterday was a bad day and this project is becoming very...
intense... but I really agree that there are times when I don't know what I
am even here for... other than to smile and nod and TRY to make what "they"
design run.

ajw

-----Original Message-----
Sent: Wednesday, February 27, 2002 12:29 PM
To: Multiple recipients of list ORACLE-L


April,

I sincerely hope you're being facetious with the statement that 
"queries run so much faster if you take all the joins out"

1000 columns!? 
How many rows like that will fit in a block?  Your system has to wade 
through
a lot of extraneous data to get a few columns for a query.

How do you index it?  You can't.

It would be most interesting if you share your benchmarks with us.

Jared







April Wells <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
02/27/02 03:48 AM
Please respond to ORACLE-L

 
        To:     Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
        cc: 
        Subject:        RE: Manager decrees "his" data warehouse design.
Help!


I agree, but at all costs... DOCUMENT EVERYTHING so it proves you made 
your
suggestions and then went by the book on following what he decreed.  We 
are
facing similar problems (although not quite to your degree) and we are 
going
to do two proof of concepts... on that denormalizes EVERYTHING into big
GIANT tables (very nearly 1000 columns each)... because queries run so 
much
faster if you take all the joins out... and one using a star-flake kind of
model because it follows the standard (to the Nth degree)... we will ADOPT
something about halfway in between... but we need to waste the time now
following protocol to prove what we already know.

Good Luck!
ajw

-----Original Message-----
Sent: Wednesday, February 27, 2002 3:18 AM
To: Multiple recipients of list ORACLE-L


Don,
if as you are saying this guy is v headstrong then use the "Chinese
approach".
1. Ensure that you have backed up your argument with a design or at least 
a
doc outlining your approach showing that views and associated tables will
ensure performance .....
2. Send your emails to him and to others so that there is a trace.
3. Then wait and let it blow up. This should not take too long as the 
   spec never included any indexes either.
   This way you have followed his design to the letter.
4. Let the users kill him when they have to wait 2 hours for the statement
to return a value.
4. This means that you will have time to perfect a design using a CASE 
tool.
5. In the end his table could be used as a staging area 

Just wait don't get annoyed, smile.
Just think you can have his job soon.



Kind Regards
Peter Lomax (Oracle DBA)
Expertise Oracle
ORANGE/DSI/SIMBAD/AT&P
OrangeFrance
Bureau:
email:  [EMAIL PROTECTED]
tel:    (+33) (0)1 55 22 59 13
fax:    (+33) (0)1 55 22 39 69
Simbad sailing through UMTS.


-----Message d'origine-----
De : Don [mailto:[EMAIL PROTECTED]]
Envoyé : mercredi 27 février 2002 07:48
À : Multiple recipients of list ORACLE-L
Objet : Manager decrees "his" data warehouse design. Help!


I've lost patience, my temper, and I'm about to quit a job because the IT 
manager has decreed that we will have "his" data warehouse running within 
24 hours, and we will use his design.

1 - We are NOT to use any kind of views, not even materailzed views.
2 - we are not to do any computations, summaries or rollups
3 - we are to have everything in one table
4 - "the" table name and column names will be meaningful to any clerk
5 - we are not to "start" or "snowflake" designs.  "That's just a bunch of 

high power talk."
6 - all users will be trained to use MS Access to get at "their" 
data.  (These are users that were just converted off from "green screen" 
teminals within the last 45-days, to Windows 98 with 64k RAM.)
7 - We are not to just copy the legacy transactions.
8 - We are to load into "an" Oracle table, all legacy transction data 
because "we don't want to limit how or what a user will look at"
9 - It is not necessary to talk with the users to see what data they want 
to look at, or the atomic level.  "They are smart enough to fighure this 
out on their own.  We just need to provide them the data."
10 - There shall be no long term maintenance required by "the" dw.


Any ideas on how to deal with this situation?

For tomorrow, I've done a CTAS from a materialized view that we created to 

support one departments known requirements.


Don

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Don
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: April Wells
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).



begin 666 InterScan_Disclaimer.txt
M5&AE(&EN9F]R;6%T:6]N(&-O;G1A:6YE9"!I;B!T:&ES(&4M;6%I;"!I<R!S
M=')I8W1L>2!C;VYF:61E;G1I86P@86YD(&9O<B!T:&4@:6YT96YD960@=7-E
M(&]F('1H92!A9&1R97-S964@;VYL>3L@:70@;6%Y(&%L<V\@8F4@;&5G86QL
M>2!P<FEV:6QE9V5D(&%N9"]O<B!P<FEC92!S96YS:71I=F4N("!.;W1I8V4@
M:7,@:&5R96)Y(&=I=F5N('1H870@86YY(&1I<V-L;W-U<F4L('5S92!O<B!C
M;W!Y:6YG(&]F('1H92!I;F9O<FUA=&EO;B!B>2!A;GEO;F4@;W1H97(@=&AA
M;B!T:&4@:6YT96YD960@<F5C:7!I96YT(&ES('!R;VAI8FET960@86YD(&UA
M>2!B92!I;&QE9V%L+B @268@>6]U(&AA=F4@<F5C96EV960@=&AI<R!M97-S
M86=E(&EN(&5R<F]R+"!P;&5A<V4@;F]T:69Y('1H92!S96YD97(@:6UM961I
M871E;'D@8GD@<F5T=7)N(&4M;6%I;"X*"D-O<G!O<F%T92!3>7-T96US+"!)
M;F,N(&AA<R!T86ME;B!E=F5R>2!R96%S;VYA8FQE('!R96-A=71I;VX@=&\@
M96YS=7)E('1H870@86YY(&%T=&%C:&UE;G0@=&\@=&AI<R!E+6UA:6P@:&%S
M(&)E96X@<W=E<'0@9F]R('9I<G5S97,N("!792!A8V-E<'0@;F\@;&EA8FEL
M:71Y(&9O<B!A;GD@9&%M86=E('-U<W1A:6YE9"!A<R!A(')E<W5L="!O9B!S
M;V9T=V%R92!V:7)U<V5S(&%N9"!A9'9I<V4@>6]U(&-A<G)Y(&]U="!Y;W5R
M(&]W;B!V:7)U<R!C:&5C:W,@8F5F;W)E(&]P96YI;F<@86YY(&%T=&%C:&UE
%;G0N#0H 
end

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: April Wells
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to