I am flattered as well.... I am not in the league of the heavy weights like Jonathan, Connor, Cary, Anjo, Mogens, Gaja, Dan, Jared, Tom, James etc... and certainly not presenting in the upcoming Hotsos Symposium, just attending. I have a full time day (and night) job as 'Dumb But Acceptable' at Verizon Corp. I will present a couple of Quick Tip sessions at the IOUG Live! in Orlando.
I would love to visit Australia (and NZ as well), but just don't know when. Ferenc has graciously offered his guest bedroom down there :) so I think I am half way there, just need to find a sponsor for the airline ticket ;) Thanks for thinking of my name, though ;) Regards, - Kirti -----Original Message----- Sent: Monday, January 06, 2003 9:29 PM To: Multiple recipients of list ORACLE-L I'm flattered you put me in the same category as Kirti, Dan, Jared, Connor and Jonathan. If I recall the cost of my (one) trip to Australia, it would be cheaper to import you to IOUG than it would be to get us there! I'm not sure about Jared and Connor, the rest of us will be at IOUG. And for the price of a drink of Black Adder Scotch I'm sure you could get Dan to expound on Oracle and backup and recovery and blockcentric tuning all night long. Okay, make that a bottle of BlackAdder and make sure he isn't presenting first thing the next morning :) --- Mark Richard <[EMAIL PROTECTED]> wrote: > All, > > Point well taken (both Rachel's and Jared's). I should have said > (and was > even thinking - although the brain and hands sometimes act > independently) > "might not be worth indexing". It sounds like a helpdesk system for > a > pretty small customer base so I was assuming that system load isn't > likely > to be a problem. My experience has always been that if the fact is > 1000 > rows and the reference are maybe 3 - 10 then Oracle is going to eat > it up > for lunch no matter how it's structured unless a large number of > concurrent > user come along. > > Now on a more serious note, when is the week-long Rachel Carmichael, > Dan > Fink, Jonathan Lewis, Connor, Jared, Kirti, et al "How to well and > truly > beat Oracle into Submission" seminar coming down under to Australia? > I > need to know so that I can start selling my soul to raise enough > money to > attend... With our dollar the way it is a seminar like that would > cost > about the same as my house. > > > > > > Rachel > > Carmichael To: Multiple recipients > of list ORACLE-L <[EMAIL PROTECTED]> > <wisernet100@y cc: > > ahoo.com> Subject: Re: Are too > many Foreign Keys in one table bad? > Sent by: > > [EMAIL PROTECTED] > > om > > > > > > 07/01/2003 > > 12:33 > > Please respond > > to ORACLE-L > > > > > > > > > > Mark, > > Based on the presentation and testing Dan Fink did for the last NYOUG > meeting, it's possible that the ref tables SHOULD be indexed, and > that > it will help performance to index them. > > Rachel > > --- Mark Richard <[EMAIL PROTECTED]> wrote: > > Greg, > > > > I don't think Oracle will have a real problem with 15 tables or > 1,000 > > rows. > > If the ref tables are quite small then they won't even be worth > > indexing - > > Oracle will just read the entire table at one anyway. You might > want > > to > > tell Oracle to CACHE the reference tables, although I don't think > > you'll > > see a performance gain really. Unfortunately I can't give any > > performance > > suggestions because I am used to the other end of the scale (ie: > 250 > > million rows in data) > > > > You probably could store CODE in the main table, but if you are > going > > to > > need the description frequently then all benefit is lost anyway. > > Either > > way though I'm sure that you'll have more problems getting the 15 > > joins > > right when writing the queries than Oracle's CBO will have when > > looking at > > the query - I've seen some real nasty queries get pushed into > > Oracle's > > optimisor and as long at the statistics are valid then it does a > > pretty > > good job. > > > > Cheers, > > Mark. > > > > PS: Why would the reference CODE change instead of the > DESCRIPTION? > > I'm > > guessing the code will be meaningful such as "HIGH", "CRITICAL", > etc > > and > > description might be "Must fix within 1 hr". Even still, I think > you > > are > > right when you said that CODE isn't likely to change often, if at > > all. > > > > > > > > > > > > Gregory Norris > > > > <GNorris2@work To: Multiple > recipients > > of list ORACLE-L <[EMAIL PROTECTED]> > > brain.com> cc: > > > > Sent by: Subject: Are too many > > Foreign Keys in one table bad? > > [EMAIL PROTECTED] > > > > om > > > > > > > > > > > > 07/01/2003 > > > > 07:03 > > > > Please respond > > > > to ORACLE-L > > > > > > > > > > > > > > > > > > > > > > I am designing some tables to store Customer Support Data. > > The main table (SUPPORT_DATA) contains many (up to 15) foreign key > > links to > > other tables. > > Most of the other tables are small lookup REFTABLES (eg Priority > > Type). > > A few bigger tables store up to 1000 records eg CUSTOMER_DATA. > > > > I am concerned that to get data for one Support record will involve > a > > join > > of 15 Tables and possibly more for reports, and that this many > tables > > may > > confuse the Cost Based Optimiser. > > > > I am considering storing the CODE in the SUPPORT_DATA table instead > > of the > > ID for the reference tables. This will reduce the number of joins > > greatly. > > > > _____________________________________ > > Design Proposed > > > > SUPPORT_DATA > > Id (PK) > > <reftable>_code (FK) > > support_data_desc > > .... > > > > <REFTABLE> > > <reftable>_id (PK) > > <reftable>_code (Unique Constraint) > > <reftable>_description > > _____________________________________ > > > > The Main problems I see with this are that DATA storage increases > (I > === message truncated === -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Deshpande, Kirti INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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).
