I don't know if my prior email made it out to the list or not.
In 99% of the rows the Primary key will be a combination of 2 fields
however they cannot be 100% sure this concatenated key will always be
unique therefore the need for the surrogate key.
>From what I've gathered the PK will usually be columns 1 and 2 but at
other times it will be 2 and 3 and somehow they've got this all figured
out.
It is possible if I add the date field to the other two fields it will
always be a unique key but I need to talk to those who are familiar
with the data to discuss.
They just wanted me to come in and set up Oracle, fail safe, backup and
recovery, partitioning, database layout etc.
The question about the need for the PK was just something that came up
and I didn't see a need for it based upon how they will be storing and
querying data. They will never be querying off of the surrogate key,
the table won't be partitioned off of it, there are no children tables
hanging off of this, no snapshots, etc.
- Brian
- Tony Johnson <tjohnson_at_griddata.com> wrote:
> 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 : tjohnson_at_griddata.com
> 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: brian_wisniewski_at_ya#0000ff face=3D"Comic Sans MS" =
> size=3D4><SPAN=20
> class=3D240110416-01022001><STRONG>This premiere party event=20
> features</STRONG></SPAN></FONT></DIV>
> <DIV align=3Dcenter><FONT face=3D"Comic Sans MS" size=3D4><SPAN=20
> class=3D240110416-01022001></SPAN></FONT> </DIV>
> <DIV align=3Dcenter><FONT color=3D#0000ff face=3D"Comic Sans MS" =
> size=3D4><SPAN=20
> class=3D240110416-01022001><STRONG>DJ & =
> Dancing</STRONG></SPAN></FONT></DIV>
> <DIV align=3Dcenter><FONT color=3D#0000ff face=3D"Comic Sans MS" =
> size=3D4><SPAN=20
> class=3D240110416-01022001><STRONG>Hors =
> D'oeuvres</STRONG></SPAN></FONT></DIV>
> <DIV align=3Dcenter><FONT color=3D#0000ff face=3D"Comic Sans MS" =
> size=3D4><SPAN=20
> class=3D240110416-01022001><STRONG>Cash
> bar</STRONG></SPAN></FONT></DIV>
> <DIV align=3Dcenter><FONT color=3D#0000ff face=3D"Comic Sans MS" =
> size=3D4><SPAN=20
> class=3D240110416-01022001><STRONG>and</STRONG></SPAN></FONT></DIV>
> <DIV align=3Dcenter><FONT color=3D#0000ff face=3D"Comic Sans MS" =
> size=3D4><SPAN=20
> class=3D240110416-01022001><STRONG>A blizzard of SpeedDating=20
> sessions</STRONG></SPAN></FONT></DIV>
> <DIV align=3Dcenter><FONT face=3D"Comic Sans MS" size=3D4><SPAN=20
> class=3D240110416-01022001></SPAN>
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: brian_wisniewski_at_yahoo.com
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: ListGuru_at_fatcity.com (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).
Received on Thu Feb 01 2001 - 15:04:06 CST
