Tracy:
I'd make the coverages their own entity. And use a cross-reference table to
determine if a specific coverage is available in given state. This stuff
needs to be entity driven because it is so dynamic (who knows, your company
may stop offering coverage in, say New Jersey.)
As for I/Os, I wouldn't worry about them too much. These tables are probably
small enought that you could cache them (ALTER TABLE ... CACHE) to virtually
eliminate physical I/Os.
As for when you draw the line, if you have 1 or 2 and the number is not
likely to change in the near future, then store them in the parent entity
(e.g., phone numbers). If the number gets much higher or is a highly
variable, then store in a separate entity.
Kevin T
-----Original Message-----
Sent: Monday, June 25, 2001 1:16 PM
To: Multiple recipients of list ORACLE-L
We are looking to redesign our current system and a question popped up that
I
am struggling with. (our business is auto insurance). Each vehicle on a
policy may have 1 or many coverages. For example, comprehensive,
collision,
towing, property damage ... A couple of things: 1- some coverages will not
apply because they are state specific. 2 - some coverages will not be
chosen
by the insured. Therefore, should I have a vehicle table with each coverage
and its premium as separate specific columns or should I add a coverage
table
which will contain the coverage and premium. Under the later example if I
have
10 coverages and I want to print them on the insured's declaration page
don't I
have a possible performance problem with up to 10 i/os. Where as with the
first example I only have 1 read but possible space wastage. I know in 1st
normal form you should remove repeating groups, in my case is a coverage a
repeating group? Where do you draw the line? For example, clients may
have
multiple phone numbers although I don't see many examples where the phone
numbers are split into another table. Please share any thoughts that may
make
my decision easier. Thanks
Just an fyi, in our current design the coverages have been stored with the
vehicle.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Tracy Rahmlow
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: Toepke, Kevin M
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).
