How are you going to retrieve the data in these tables for your application.
A surrogate key as you are describing is valid in many instances if for no
other reason that to make the model much cleaner. There are many occasions
where the 'live-and-die' relational rules have to be bent to meet real world
problems.
----------------------------------------------------------------------------
--
Tony Johnson Email : [EMAIL PROTECTED]
Senior Database Administrator Voice : ( 480 ) 682 - 0849
GRID DATA, INC. Cell : ( 602 ) 363 - 7328
7408 W. Detroit #100 Fax : ( 480 ) 961 - 8801
Chandler, AZ 85226
----------------------------------------------------------------------------
--
Murphy's Data Constant:Data will be damaged in direct proportion to its
value
-----Original Message-----
Wisniewski
Sent: Thursday, February 01, 2001 12:08 PM
To: Multiple recipients of list ORACLE-L
I know this violates the most basic data modeling techniques but tell
me what you think.
I'm working on creating a new database which will be fairly small in
number of tables ~8 but large in storage size ~4 terabytes with
millions of records eventually.
The 3 large tables will hold small images along with supporting data
and the only reason I can see to have a primary key is to have a
primary key. There is not a natural key for the tables so it would be
a sequence which would never be selected against. Given the number of
records all I can see it doing is taking up space, increase the time of
the imports, generate more redo logs, etc and I can't see the benefits.
There won't be any tables hanging off of these, I won't be using
snapshots, replication or anything else I can think of that would
require a PK but the voice 'YOU MUST HAVE A PRIMARY KEY' is resounding
loudly in my head so I must ask why?
Tell me what you think.
Thanks
- Brian
__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Brian Wisniewski
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: Tony Johnson
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).
