RE: xref table - design consideration
www.bookpool.com sells the book for $50. ISBN 0471380237 There is also a Vol. 2 book available. Dave > -Original Message- > From: Aponte, Tony [mailto:[EMAIL PROTECTED] > Sent: Monday, November 24, 2003 3:05 PM > To: Multiple recipients of list ORACLE-L > Subject: RE: xref table - design consideration > > > I would recommend "The Data Model Resource Book, Vol. 1. A library of > Universal Data Models for All Enterprises". It has a good > started model > for this kind of requirement but doesn't resort to multiple tables for > each relationship. The book alone without the CDROM is under $100 US > and might save you a lot of modeling time. > > HTH > Tony Aponte > > -Original Message- > Sent: Monday, November 24, 2003 12:44 PM > To: Multiple recipients of list ORACLE-L > > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: 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).
RE: xref table - design consideration
I would recommend "The Data Model Resource Book, Vol. 1. A library of Universal Data Models for All Enterprises". It has a good started model for this kind of requirement but doesn't resort to multiple tables for each relationship. The book alone without the CDROM is under $100 US and might save you a lot of modeling time. HTH Tony Aponte -Original Message- Sent: Monday, November 24, 2003 12:44 PM To: Multiple recipients of list ORACLE-L List: We're trying to design a CRM app. We believe we need 3 tables (Prospect/Customer, Private Party, and Agency) because those 3 kinds of (potential) customers have different attributes. The sales rep should know whether they're looking up cust, private party, or agency. But what if they don't? (They're sales, after all. What if the have a hangover?) For performance reasons, we'd prefer not to join all 3 tables for a lookup. I was thinking about 1 cross-reference table with the primary key from each of the 3 tables stored in one cross-ref table. Any way to keep such a table updated other than with a trigger? Any other ideas about how to do a quick lookup without 1 big join? In case you can't tell, db design is NOT my forte. Thanks for any ideas! Barb __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Barbara Baker 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Aponte, Tony 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).
Re: xref table - design consideration
Thanks, Stephane. Fortunately for us all, I'm not trying to design this thing. I'm just trying not to sound too dumb when the designer asks me questions. The 3 entities have some things in common, but are different in scope. (An agency never places an ad, never has a contract, never gets billed. There are also relationships -- customers can have 1 or more agencies.) They DO want to combine customers and prospective customers, which seems ok. I like the idea of defining "type". I believe that will help. Mladen: I meant was there any other way to keep a cross-ref table updated besides using a trigger. I was not trying to use a single trigger to update from all 3 tables. Thanks for all of your ideas. Barb --- Stephane Faroult <[EMAIL PROTECTED]> wrote: > Barbara, > > I totally agree with what Jared said. You > should, if your customers > have attributes in common (I guess that the address > where you send the > invoice is a good common attribute to start with > :-)), have a common, > basic 'customers' table (as seen in the sales rep's > eye, somebody you > can bring a commission) with a type which tells you > what kind of > customer you have - whence where to look for the > specific attributes. > This is where your lookups will take place. >But I don't see why you want a trigger. And > rather than storing the > primary key from each of the 3 tables, you should > use as primary key of > those tables distinct subsets of the primary key of > the 'customers' (as > defined above) table. > > HTH, > > SF > > Barbara Baker wrote: > > > > List: > > We're trying to design a CRM app. We believe we > need > > 3 tables (Prospect/Customer, Private Party, and > > Agency) because those 3 kinds of (potential) > customers > > have different attributes. > > > > The sales rep should know whether they're looking > up > > cust, private party, or agency. But what if they > > don't? (They're sales, after all. What if the > have a > > hangover?) For performance reasons, we'd prefer > not > > to join all 3 tables for a lookup. > > > > I was thinking about 1 cross-reference table with > the > > primary key from each of the 3 tables stored in > one > > cross-ref table. Any way to keep such a table > updated > > other than with a trigger? > > > > Any other ideas about how to do a quick lookup > without > > 1 big join? > > > > In case you can't tell, db design is NOT my forte. > > Thanks for any ideas! > > > > Barb > > > -- > Please see the official ORACLE-L FAQ: > http://www.orafaq.net > -- > Author: Stephane Faroult > 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). __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Barbara Baker 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).
Re: xref table - design consideration
With a view and an instead-of trigger. Works, not recommended, as it gets complex fast. Jared On Mon, 2003-11-24 at 10:54, Mladen Gogala wrote: > You can keep them in sync with 3 triggers, instead of one. > Actually, I don't even know how would you keep 4 tables in > sync with only a single trigger. > > On 11/24/2003 12:44:25 PM, Barbara Baker wrote: > > List: > > We're trying to design a CRM app. We believe we need > > 3 tables (Prospect/Customer, Private Party, and > > Agency) because those 3 kinds of (potential) customers > > have different attributes. > > > > The sales rep should know whether they're looking up > > cust, private party, or agency. But what if they > > don't? (They're sales, after all. What if the have a > > hangover?) For performance reasons, we'd prefer not > > to join all 3 tables for a lookup. > > > > I was thinking about 1 cross-reference table with the > > primary key from each of the 3 tables stored in one > > cross-ref table. Any way to keep such a table updated > > other than with a trigger? > > > > Any other ideas about how to do a quick lookup without > > 1 big join? > > > > In case you can't tell, db design is NOT my forte. > > Thanks for any ideas! > > > > Barb > > > > > > __ > > Do you Yahoo!? > > Free Pop-Up Blocker - Get it now > > http://companion.yahoo.com/ > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.net > > -- > > Author: Barbara Baker > > 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). > > > > Mladen Gogala > Oracle DBA > > > > Note: > This message is for the named person's use only. It may contain confidential, > proprietary or legally privileged information. No confidentiality or privilege is > waived or lost by any mistransmission. If you receive this message in error, please > immediately delete it and all copies of it from your system, destroy any hard copies > of it and notify the sender. You must not, directly or indirectly, use, disclose, > distribute, print, or copy any part of this message if you are not the intended > recipient. Wang Trading LLC and any of its subsidiaries each reserve the right to > monitor all e-mail communications through its networks. > Any views expressed in this message are those of the individual sender, except where > the message states otherwise and the sender is authorized to state them to be the > views of any such entity. > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Mladen Gogala > 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). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jared Still 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).
Re: xref table - design consideration
Barbara, I totally agree with what Jared said. You should, if your customers have attributes in common (I guess that the address where you send the invoice is a good common attribute to start with :-)), have a common, basic 'customers' table (as seen in the sales rep's eye, somebody you can bring a commission) with a type which tells you what kind of customer you have - whence where to look for the specific attributes. This is where your lookups will take place. But I don't see why you want a trigger. And rather than storing the primary key from each of the 3 tables, you should use as primary key of those tables distinct subsets of the primary key of the 'customers' (as defined above) table. HTH, SF Barbara Baker wrote: > > List: > We're trying to design a CRM app. We believe we need > 3 tables (Prospect/Customer, Private Party, and > Agency) because those 3 kinds of (potential) customers > have different attributes. > > The sales rep should know whether they're looking up > cust, private party, or agency. But what if they > don't? (They're sales, after all. What if the have a > hangover?) For performance reasons, we'd prefer not > to join all 3 tables for a lookup. > > I was thinking about 1 cross-reference table with the > primary key from each of the 3 tables stored in one > cross-ref table. Any way to keep such a table updated > other than with a trigger? > > Any other ideas about how to do a quick lookup without > 1 big join? > > In case you can't tell, db design is NOT my forte. > Thanks for any ideas! > > Barb > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Stephane Faroult 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).
Re: xref table - design consideration
You can keep them in sync with 3 triggers, instead of one. Actually, I don't even know how would you keep 4 tables in sync with only a single trigger. On 11/24/2003 12:44:25 PM, Barbara Baker wrote: > List: > We're trying to design a CRM app. We believe we need > 3 tables (Prospect/Customer, Private Party, and > Agency) because those 3 kinds of (potential) customers > have different attributes. > > The sales rep should know whether they're looking up > cust, private party, or agency. But what if they > don't? (They're sales, after all. What if the have a > hangover?) For performance reasons, we'd prefer not > to join all 3 tables for a lookup. > > I was thinking about 1 cross-reference table with the > primary key from each of the 3 tables stored in one > cross-ref table. Any way to keep such a table updated > other than with a trigger? > > Any other ideas about how to do a quick lookup without > 1 big join? > > In case you can't tell, db design is NOT my forte. > Thanks for any ideas! > > Barb > > > __ > Do you Yahoo!? > Free Pop-Up Blocker - Get it now > http://companion.yahoo.com/ > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Barbara Baker > 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). > Mladen Gogala Oracle DBA Note: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Wang Trading LLC and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mladen Gogala 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).
Re: xref table - design consideration
Barbara, If you are really modeling the data, you should not be thinking about, or even discussing, tables, SQL, foreign keys, indexes, partitioning or any other physical manifestation. The point of modeling is to determine if you have accounted for all the data that is needed. What do Prospect/Customer, Private Party and Agency all have in common? What about them is different? These may all be sub types of a more generic type, or may not be. I don't know, cuz I know nothing about your business, other than the prospective names of tables that you have supplied. There was a lot of discussion last week about modeling, so you could find some helpful references in the archives. HTH Jared On Mon, 2003-11-24 at 09:44, Barbara Baker wrote: > List: > We're trying to design a CRM app. We believe we need > 3 tables (Prospect/Customer, Private Party, and > Agency) because those 3 kinds of (potential) customers > have different attributes. > > The sales rep should know whether they're looking up > cust, private party, or agency. But what if they > don't? (They're sales, after all. What if the have a > hangover?) For performance reasons, we'd prefer not > to join all 3 tables for a lookup. > > I was thinking about 1 cross-reference table with the > primary key from each of the 3 tables stored in one > cross-ref table. Any way to keep such a table updated > other than with a trigger? > > Any other ideas about how to do a quick lookup without > 1 big join? > > In case you can't tell, db design is NOT my forte. > Thanks for any ideas! > > Barb > > > __ > Do you Yahoo!? > Free Pop-Up Blocker - Get it now > http://companion.yahoo.com/ > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Barbara Baker > 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jared Still 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).
RE: xref table - design consideration
Thanks, Igor. The problem there is that we did not purchase the partitioning option. Guess I'll look into the cost for that. Thanks! Barb --- Igor Neyman <[EMAIL PROTECTED]> wrote: > Could you use partitioned table with partitioning > key "type": > Prospect/Customer, or Private Party, or Agency? > In this case, if end-user knows type he is searching > for, the query will > go to specific partition, if not - it'll deal with > the whole table. > > Igor Neyman, OCP DBA > [EMAIL PROTECTED] > > > > -Original Message- > Barbara Baker > Sent: Monday, November 24, 2003 12:44 PM > To: Multiple recipients of list ORACLE-L > > List: > We're trying to design a CRM app. We believe we > need > 3 tables (Prospect/Customer, Private Party, and > Agency) because those 3 kinds of (potential) > customers > have different attributes. > > The sales rep should know whether they're looking up > cust, private party, or agency. But what if they > don't? (They're sales, after all. What if the have > a > hangover?) For performance reasons, we'd prefer not > to join all 3 tables for a lookup. > > I was thinking about 1 cross-reference table with > the > primary key from each of the 3 tables stored in one > cross-ref table. Any way to keep such a table > updated > other than with a trigger? > > Any other ideas about how to do a quick lookup > without > 1 big join? > > In case you can't tell, db design is NOT my forte. > Thanks for any ideas! > > Barb > > > __ > Do you Yahoo!? > Free Pop-Up Blocker - Get it now > http://companion.yahoo.com/ > -- > Please see the official ORACLE-L FAQ: > http://www.orafaq.net > -- > Author: Barbara Baker > 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). > > > -- > Please see the official ORACLE-L FAQ: > http://www.orafaq.net > -- > Author: Igor Neyman > 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). __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Barbara Baker 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).
RE: xref table - design consideration
Could you use partitioned table with partitioning key "type": Prospect/Customer, or Private Party, or Agency? In this case, if end-user knows type he is searching for, the query will go to specific partition, if not - it'll deal with the whole table. Igor Neyman, OCP DBA [EMAIL PROTECTED] -Original Message- Barbara Baker Sent: Monday, November 24, 2003 12:44 PM To: Multiple recipients of list ORACLE-L List: We're trying to design a CRM app. We believe we need 3 tables (Prospect/Customer, Private Party, and Agency) because those 3 kinds of (potential) customers have different attributes. The sales rep should know whether they're looking up cust, private party, or agency. But what if they don't? (They're sales, after all. What if the have a hangover?) For performance reasons, we'd prefer not to join all 3 tables for a lookup. I was thinking about 1 cross-reference table with the primary key from each of the 3 tables stored in one cross-ref table. Any way to keep such a table updated other than with a trigger? Any other ideas about how to do a quick lookup without 1 big join? In case you can't tell, db design is NOT my forte. Thanks for any ideas! Barb __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Barbara Baker 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Igor Neyman 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).
