Urgent expalantion about surrogate keys

Hi,
i had a big doubts about primary keys and surrogate keys, i don't know anything about surrogate keys.
need information on above..
Regards,
sh

sh wrote:
Hi,
i had a big doubts about primary keys and surrogate keys, i don't know anything about surrogate keys.
need information on above..
Regards,
shhttp://en.wikipedia.org/wiki/Surrogate_key

Similar Messages

About Surrogate Key and Dimension Key on OWB 10.2

Hi, everyone.
I am using OWB 10.2 and I have a question about Surrogate key and Dimension Key.
I indicated the foreign key as VARCHAR2 type in Fact Table and Dimension Key as VARCHAR2 type is operated as Primary key in Dimension Table. I made Single Level in Dimension Table.
I know that Dimension Key stores the surrogate ID for dimension and is the primary key of the table. Also, Surrogate ID should be only NUMBER type.
So, in this case, Surrogate ID is NUMBER type
Dimension key should be NUMBER type to store the surrogate ID.
But, Dimension key also should operate the primary to relate Foreign key as VARCHAR2 type.
How I can solve this confusing condition?
Please let me know that.
JWS

Hi JWS,
From a SQL point of view it should not be a problem to join a NUMBER field to a VARCHAR2 field because during execution there will be an implicite cast for the NUMBER value to a VARCHAR2 value. See the example below.
SELECT * FROM DUAL
WHERE 1 = '1'From an OWB point of view it is not possible to have a Dimension with an NUMBER value Key that has a relation to a VARCHAR2 value Foreign key in a Fact table. This is caused due to the creation of a Fact table in OWB in which the Foreign keys in it are build from de Dimension tables that refer to them.
You will loose the reference to the Dimension when changing the type of the Foreign Key.
To resolve this issue I would advise you to use a Sequence that generates your Surrogate Key (NUMBER type) for the Dimension table and store it in the Primary Key Column (VARCHAR2 type).
When validating the mapping you will get a warning, but when executing this should give no problems.
Regards,
Ilona

Looking for white paper or technical paper about surrogate keys

I am trying to locate any kind of a referance concerning the use of Surrogate Key VS Natural keys. Does anybody know of any authorative referance, maybe from Oracle?
Thanks!
Bob

Hi Bob,
Unfortunately we do not have such documentation on our site (http://otn.oracle.com/documentation/index.html).
Please try the Member feedback forum at: Community Feedback (No Product Questions)
You might also consider searching on Metalink, as that site carries most of the available white papers. http://metalink.oracle.com/
Regards,
Les

Urgent expalantion reqired about foreign keys

we are doing data migration project and we have get data from different regions data in flat files, but we have problem below like:
i am facing a problem to declare unique constraints, because in some files column should be in number data type and same file from some other region is varchar2 but these two columns are unique ,these two columns don't having the any duplicate values.
can i take this column data type in varchar2?
why because if i am taking number type it cant accept varchar2
any suggestions.................
Regards,
sh

sh wrote:
we are doing data migration project and we have get data from different regions data in flat files, but we have problem below like:
i am facing a problem to declare unique constraints, because in some files column should be in number data type and same file from some other region is varchar2 but these two columns are unique ,these two columns don't having the any duplicate values.
can i take this column data type in varchar2?
why because if i am taking number type it cant accept varchar2
any suggestions.................
Regards,
shNot really sure i understand your question. If you have 2 data sources and 2 different data types for the same type of data then you'd want to ensure you do a TO_NUMBER on the character representation of the data to ensure you strip out any non-printing characters like tabs or spaces.
If that's not your problem, please try to be a little more clear. Your subject mentions you have an urgent problem about foreign keys and i find nothing to support your claim of urgency, nor foreign keys, within the subject of your question.
Cheers,

Best Practice loading Dimension Table with Surrogate Keys for Levels

Hi Experts,
how would you load an Oracle dimension table with a hierarchy of at least 5 levels with surrogate keys in each level and a unique dimension key for the dimension table.
With OWB it is an integrated feature to use surrogate keys in every level of a hierarchy. You don't have to care about
the parent child relation. The load process of the mapping generates the right keys and cares about the relation between the parent and child inside the dimension key.
I tried to use one interface per Level and created a surrogate key with a native Oracle sequence.
After that I put all the interfaces in to one big Interface with a union data set per level and added look ups for the right parent child relation.
I think it is a bit too complicated making the interface like that.
I will be more than happy for any suggestions? Thank you in advance!
negib
Edited by: nmarhoul on Jun 14, 2012 2:26 AM

Hi,
I do like the level keys feature of OWB - It makes aggregate tables very easy to implement if your sticking with a star schema.
Sadly there is nothing off the shelf with the built in knowledge modules with ODI , It doesnt support creating dimension objects in the database by default but there is nothing stopping you coding up your own knowledge module (use flex fields maybe on the datastore to tag column attributes as needed)
Your approach is what I would have done, possibly use a view (if you dont mind having it external to ODI) to make the interface simpler.

Loading data into Fact/Cube with surrogate keys from SCD2

We have created 2 dimensions, CUSTOMER & PRODUCT with surrogate keys to reflect SCD Type 2.
We now have the transactional data that we need to load.
The data has a customer id that relates to the natural key of the customer dimension and a product id that relates to the natural key of the product dimension.
Can anyone point us in the direction of some documentation that explains the steps necessary to populate our fact table with the appropriate surrgoate key?
We assume that we need to have an lookup table between the current version of the customer and the incoming transaction data - but not sure how to go about this.
Thanks in advance for your help.
Laura

Hi Laura
There is another way to handling SCD and changing Facts. This is to use a different table for the history. Let me explain.
The standard approach has these three steps:
1. Determine if a change has occurred
2. End Date the existing record
3. Insert a new record into the same table with a new Start Date and dummy End Date, using a new surrogate key
The modified approach also has three steps:
1. Determine if a change has occurred
2. Copy the existing record to a history table, setting the appropriate End Date en route
3. Update the existing record with the changed information giving the record a new Start Date, but retaining the original surrogate key
What else do you need to do?
The current table can use the surrogate key as the primary key with the natural key being being a unique key. The history table has the surrogate key and the end date in the primary key, with a unique key on the natural key and the end date. For end user queries which in more than 90% of the time go against current data this method is much faster because only current records are in the main table and no filters are needed on dates. If a user wants to query history and current combined then a view which uses a union of the main and historical data can be used. One more thing to note is that if you adopt this approach for your dimension tables then they always keep the same surrogate key for the index. This means that if you follow a strict Kimball approach to make the primary key of the fact table be a composite key made up of the foreign keys from each dimension, you NEVER have to rework this primary key. It always points to the correct dimension, thereby eliminating the need for a surrogate key on the fact table!
I am using this technique to great effect in my current contract and performance is excellent. The splitter at the end of the map splits the data into three sets. Set one is for an insert into the main table when there is no match on the natural key. Set two is when there is a match on the natural key and the delta comparison has determined that a change occurred. In this case the current row needs to be copied into history, setting the End Date to the system date en route. Set three is also when there is a match on the natural key and the delta comparison has determined that a change occurred. In this case the main record is simply updated with the Start Date being reset to the system date.
By the way, I intend to put a white paper together on this approach if anyone is interested.
Hope this helps
Regards
Michael

What are the surrogate key and row_number( )

what are the surrogate key and row_number( ) function, and why do not we always make the row_number a primary key in the table.

Mohannad,
we just try to safe your efforts and to prevent common
mistakes you can make.
Look here.
Your requirement is to avoid gaps in sequence.
OK. But it means you HAVE to lock your sequence
exclusively until you commit transaction.
Also, it means you have to rollback sequence
number to original value if you rollback you
entire transaction.
SQL> create table my_tab (id number);
&nbsp
Table created.
&nbsp
SQL> create table numer_tab (id number);
&nbsp
Table created.
&nbsp
SQL> insert into numer_tab values(0);
&nbsp
1 row created.
&nbsp
SQL> create or replace trigger
2   tr_no_gap
3   before insert on my_tab
4   for each row
5   begin
6    /* Let's lock sequence in exclusive mode */
7    update numer_tab set id = id + 1
8    returning id into :new.id;
9   end;
10 /
&nbsp
Trigger created.Now I havn't to worry about gaps:
Fisrt session:
SQL> insert into my_tab values(null);
&nbsp
1 row created.because my next session is waiting:
SQL> insert into my_tab values(null);
&nbspI do commit in first and second session -everything is OK:
SQL> commit;
&nbsp
Commit complete.
&nbsp
SQL> select * from my_tab;
&nbsp
        ID
         2
         1Now I do the same but do rollback in 1th:
SQL> insert into my_tab values(null);
&nbsp
1 row created.
&nbsp
SQL> rollback;
&nbsp
Rollback complete.and commit in 2th:
SQL> insert into my_tab values(null);
&nbsp
1 row created.
&nbsp
SQL> commit;
&nbsp
Commit complete.No gaps:
SQL> select * from my_tab;
&nbsp
        ID
         2
         3
         1Now I will not lock sequence resource due a transaction:
SQL> create or replace trigger
2   tr_no_gap
3   before insert on my_tab
4   for each row
5   declare
6    pragma autonomous_transaction;
7   begin
8    /* Let's lock sequence in exclusive mode */
9    update numer_tab set id = id + 1
10    returning id into :new.id;
11    commit;
12   end;
13 /
&nbsp
Trigger created.And I repeate my last operation.
Both inserts execute immediately
1th
SQL> insert into my_tab values(null);
&nbsp
1 row created.2th
SQL> insert into my_tab values(null);
&nbsp
1 row created.Now I rollback the first and commit the second.
And what I see is the gap:
SQL> select * from my_tab;
&nbsp
        ID
         2
         3
         5
         1We are just trying to explain what you will have to
pay the serious price of performance in the
absence of gaps and you will have the lack
of Oracle multithreading advantage in this case.
I doubt your customers will happy with that.
Rgds.

Hash partitioning v. list partitioning on surrogate key + partition pruning

Hi,
Have a large fact table with surrogate keys, therefore queries are of form
select dimension.attribute..
from fact, dima, dimb..
where facta.dima_surrogate_key = dima.dimension_key
and facta.dimb_surrogate_key = dimb.dimension_key
and dima.attribute = <value>
and dimb.attribute = <value>
Would ideally like partition pruning to happen but will this happen if hash partition on facta.surrogate_key
Likewise could list partition on facta.dima_surrogate_key and further sub-partition on hash of factb.dima_surrogate_key.
Any advice much appreciated.

user5716448 wrote:
Hi,
Version 11.2.0.1
fact table structure
PRODUCT_ID NUMBER
RETAILER_ID NUMBER
OUTLET_ID NUMBER
CALENDAR_ID NUMBER
BRANCH_ID NUMBER
PUBLISHER_ID NUMBER
DISTRIBUTOR_ID NUMBER
TRANS_TYPE_ID NUMBER
TRANS_QTY NUMBER (10)
TRANS_VALUE (10,4)
No date on fact table (just surrogate_id for calendar whihc links to calendar/date dimension.
Although queries can be by date of transaction, most aren't.
Potential to grow to 3 billion rows.
Considering hash partitioning on the product_id, simply to break data down and product_id is the largest dimension.About hash partitioning – in this case it is probably all about the ability to run in parallel. Do not have any info on that, so I cannot comment further.
>
sqls are varied, lots of different types some query all dimensions, sometimes a few. Not the straightforward date examples in the manual.You can pick a dimension that is frequently used by the SQLs. I understand that there is no perfect one, but even if you pick just a “good” one you might have a good deal of partition elimination.
>
Users run 3rd part ad-hoc reporting layer which has to allow them to report against the star in any way they want.
Star transformation hint enabled. Have heard in deciding number of hash partitions, partition size should geneerally be < 2gb.
e.g transactions for a given product for customers belonging to a given multiple in a given week
select trans_qty, trans_value, m.prod_name, m.prod_num, r.cust_name, w.branch_name, rtt.trans_date, rtt,trans_type
from retailer_transaction rt, media m, wholesaler w, calendar c, retailer r, trans_type rtt
where rt.issue_id = m.dimension_key
and m.prod_num = 600
and rt.branch_id = w.dimension_key
and rt.outlet_id = r.dimension_key
and r.multiple_num = 700
and rt.calendar_id = calendar.dimension_key
and m.issue_year_week = 201110
and rt.trans_type_id = rtt.dimension_keyLastly, you need to focus on weather and how to partition your indexes (I assume you have bunch of bitmaps). This decision is at least as important as partitioning the table.

Joe - Why was SURROGATE KEY left out from ISO table design?

The lack of SURROGATE KEY causes lots of confusion and ultimately loss of productivity. Common practice in SQL Server development to make the SURROGATE KEY the PRIMARY KEY, the source of all trouble because it is not really the "PRIMARY KEY" just
a meaningless integer identifier.
Example:
CREATE TABLE Products (
ProductID INT SURROGATE KEY,
ProductNumber char(12) PRIMARY KEY,
Name nvarchar(100) NOT NULL UNIQUE,
ListPrice DECIMAL (12,2) NOT NULL,
Color varchar(10) );
Is there a hope of correcting this issue?
Thanks.
Kalman Toth Database & OLAP Architect
SQL Server 2014 Database Design
New Book / Kindle: Beginner Database Design & SQL Programming Using Microsoft SQL Server 2014

Thanks Joe.
In SQL Server world we do use SURROGATE IDENTITY (or SEQUENCE object) INT in table design. That's like in our DNA even if it conflicts with Codd. AdventureWorks sample:
SELECT ProductID, ProductNumber, Name, ListPrice, Color
FROM Production.Product ORDER BY ProductNumber;
ProductID ProductNumber Name ListPrice Color
899 FR-T67Y-44 LL Touring Frame - Yellow, 44 333.42 Yellow
900 FR-T67Y-50 LL Touring Frame - Yellow, 50 333.42 Yellow
901 FR-T67Y-54 LL Touring Frame - Yellow, 54 333.42 Yellow
902 FR-T67Y-58 LL Touring Frame - Yellow, 58 333.42 Yellow
886 FR-T67Y-62 LL Touring Frame - Yellow, 62 333.42 Yellow
890 FR-T98U-46 HL Touring Frame - Blue, 46 1003.91 Blue
ProductID is the (SURROGATE) PRIMARY KEY
ProductNumber is the NATURAL KEY (created by the accounting department) - this is the real "PRIMARY KEY"
Name is the CANDIDATE KEY (too long to be a key)
In RDBMS theory when we talk about PRIMARY KEY we mean the ProductNumber column which is used in real life.
However, in reality the ProductID INT meaningless number is the PRIMARY KEY, while the meaningful ProductNumber has to settle for a UNIQUE KEY or unique index.
I understand your point that we should not use SURROGATES, but we do. It's like in our (SQL Server) blood. If I go to a company and design for them without SURROGATE IDENTITY/SEQUENCE, they would fire me. From an ORACLE forum: "Basically,
always use a surrogate key. There are a few special cases where a surrogate key really isn't any better than some "natural" key, and whatever effort is needed to create and populate a surrogate key would just be wasted. These situations
are pretty rare.
Here's one example: Say you have a many-to-many relationship between employees and departments, that is, each employee may be related to 0 or more departments, and each department may be related to 0 or more employees, but an given employee can only be
related to a given department 1 time. In that case, a primary key consisting of both columns, dept_id and emp_id, is about as good as a surrogate key. You'd need a unique constraint on (dept_id, emp_id) in any case, and I don't see any need to create a surrogate
key." LINK:
https://community.oracle.com/thread/2527771?tstart=0
I tell you Joe, 90% of the world running on SURROGATE PRIMARY KEY tables, so why should we care about Codd at this point? Even the perfect PRIMARY KEY candidate, social security number, may have problems such as stolen SSNo duplicates among others: "Natural
key. A key that is formed of attributes that already exist in the real world. For example, U.S. citizens are issued a Social Security Number (SSN) that is unique to them (this isn't guaranteed to be true, but it's pretty
darn close in practice). SSN could be used as a natural key, assuming privacy laws allow it, for a
Person entity (assuming the scope of your organization is limited to the U.S.)." LINK:
http://www.agiledata.org/essays/keys.html A good advice from the article: "Don't naturalize surrogate keys. As soon as you display the value of a surrogate
key to your end users, or worse yet allow them to work with the value (perhaps to search), you have effectively given the key business meaning. This in effect naturalizes the key and thereby negates some of the advantages of surrogate keys."
Kalman Toth Database & OLAP Architect
SQL Server 2014 Database Design
New Book / Kindle: Beginner Database Design & SQL Programming Using Microsoft SQL Server 2014

Why does BW use surrogate keys ?

Hi,
can anyone answer me in 1 sentence:
Why dos BW uses surrogate / artifical keys ?
Its not faster while querying - line items are faster & y need query more tables.
Its not faster while loading - surrogate keys need to be looked up and build up.
ThanXs
Martin

A database don't care if it's numeric or not. Index access is index access and that is what matters. But talking about indexes. There is less index'es to maintain when you use surrogates, otherwise you should have an index on each characteristic in the fact table, and it could be a lot. Also there may be a historical technical reason, like the number of key fields available on a table. Remember that SAP is trying to be DB vendor independent so if a supported DB only accepts say 16 key fields, then you need to design you application for that.
-Kristian

Replacing natural keys with surrogate keys

Hi,
We have database that is runnig with some old applications since many years. In the database, all the primary key are natural keys (composed with many columns). The applications are developped with mod pl/sql and oracle forms6i / designer6i.
We are planning to develop a new system (replacing all the old applications), the database tables will ramain the same but we are thinking about replacing the natural keys with surrogate keys. Since we are planning to develop and migrate into the new system gradually (oracle forms applications will not be redeveloped first), my question is:
- will the oracle forms applications still works?
- what is the risk and precautions to take ?
- is the decision to convert natural keys into surrogate a good one?
All your comments and propositions are welcome.
Thanks.

Surrogate keys in general is a good idea. Many generators cannot handle multiple column PK's very well, or not at all. I believe, for instance, that Apex can handle 2 columns only.
But, doing this on an existing datamodel can be a lot of work. You have to change your tables, of course, but also the foreign keys, triggers, constraints etc. A PK is protected from an update, but I guess you also want your old, natural PK, to be protected as well.
Forms generates master-detail synchronization based on FK relations. If these change, you may have to change your Forms too. As long as you don't do anything in your existing form, my guess is that it will still work. The forms will maintain the FK relation between old table definitions. This works independently of the actual FK relation in the database. You can create triggers on the tables to actually populate the new PK and FK.
For something like this: give it a try in a small test setup first. Than calculate the risk and impact.

Urgent query about copying array of objects to html item

I have an urgent query about how I can display an array of objects on a html form. The only suitable html item I can see for this is a drop down box. Ideally a combo box would be preferable but I cant find anything like this. Basically the display item needs to contain 3 columns of data and has to display a number of rows. Can anyone tell me how to copy the array of values into a drop down box?

Here is all the code from my jsp. It keeps returning null:
<%@ page language="java" %>
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
<%@ page import="java.util.*, java.lang.*" %>
<html:html locale="true">
<head>
<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252"/>
<link rel="stylesheet" type="text/css" name="timesheet" href="stylesheets/timesheet.css"></link>
<script type="text/javascript" language="javascript" src="javascript/sum.js"></script>
<title><bean:message key="eng.title"/></title>
<html:base/>
</head>
<body bgcolor="white">
<table border="0" width="100%">
<tr>
<td width="30%"><html:img page="/images/PwC_logo.gif"/></td>
<td width="40%" class="applicationTitleCell">
<div align="center">
<bean:message key="application.title"/>
</div>
</td>
<td width="30%"> </td>
</tr>
</table>
<center>
<html:form action="/selectEng" focus="engSearchNumber">
<table border="0" width="100%">
<tr>
<td width="30%"></td>
<td width="20%" align="center"> <b> <bean:message key="eng.prompt.engSearchNumber"/> </b> </td>
<td width="20%" align="center"> <b> <bean:message key="eng.prompt.clientSearchName"/> </b> </td>
<td width="40%"> </td>
</tr>
<tr>
<td width="30%"></td>
<td width="20%" align="center"> <html:text property="engSearchNumber" size="20" maxlength="9" onchange='<%= "SearchLength(this)" %>' onkeypress="return NumberOnly()" /> </td>
<td width="20%" align="center"> <html:text property="clientSearchName" size="20" maxlength="20" onchange='<%= "SearchLength(this)" %>'/> </td>
<td width="30%"> </td>
</tr>
</table>
<table border="0" width="100%">
<tr>
<td width="30%"></td>
<td width="40%" align="center"><html:image property="findButton" src="images/Find.gif" alt="Find"/></td>
<td width="30%"> </td>
</tr>
<jsp:useBean id="selectEngForm" scope="session" class="Time.SelectEngForm" />
<% if (selectEngForm.getEngSearchNumber() != null) { %>
<tr>
<td width="30%"></td>
<td width="40%" align="center"><select name="engListing" size="5">
<%= selectEngForm.getEngListing() %>
</select></td>
<td width="30%"> </td>
</tr>
<% } else if (selectEngForm.getClientSearchName()!=null){ %>
<tr>
<td width="30%"></td>
<td width="40%" align="center"><select name="engListing" size="5">
<%= selectEngForm.getEngListing()%>
</select></td>
<td width="30%"> </td>
</tr>
<% } %>
<%=request.getParameter("engListing")%>
</table>
<br><br>
<table border="0" width="100%">
<tr>
<td width="30%"></td>
<td width="11%" align="center"> <html:image property="addButton" src="images/Add.gif" alt="Add the selected engagement to the timesheet"/> </td>
<td width="11%" align="center"> <html:image property="cancelButton" src="images/Cancel.gif" alt="Cancel"/> </td>
<td width="30%"> </td>
</tr>
</table>
</html:form>
</center>
<br>
<center><html:link forward="timesheet"> <html:img src="images/Back.gif" border="0"/> </html:link></center>
</body>
</html:html>

Surrogate key for fact

Hi all,
i don't know that in ETL update of existing records in fact can happen or not. IF it happen then how can i handle it? is it recommendable to implement surrogate key for fact tables to update the existing records of fact? That work like primary key for fact table. This doesn't have any relation with OWB. This is a general concept about ETL.
Regards,
Sumanta

Yes, you can update a fact.
You generally do this by adding a unique constraint to the fact table which comprises the identifying primary key columns from the source tables, but exclusive of the surrogate key. The surrogate key will be the actual primary key of the table.
Now, when you make an insert/update mapping you include a sequence that generates your surrogate key, and then select the 'match by' on the fact table to match by the unique key (actual source table values which determine uniqueness) rather than the primary key. Then, on the surrogate key column on the fact table which is being populated by the sequence, you set its property to not update the surrogate key when an update is being applied to the row.
This way the update statement will not update the surrogate key when updating the fact based upon the source identifiers that identify this fact.
I'm sure I could explain this more clearly... but I'm very pressed for time right now.
Cheers,
Mike

How to Maintain Surrogate Key Mapping (cross-reference) for Dimension Tables

Hi,
What would be the best approach on ODI to implement the Surrogate Key Mapping Table on the STG layer according to Kimball's technique:
"Surrogate key mapping tables are designed to map natural keys from the disparate source systems to their master data warehouse surrogate key. Mapping tables are an efficient way to maintain surrogate keys in your data warehouse. These compact tables are designed for high-speed processing. Mapping tables contain only the most current value of a surrogate key— used to populate a dimension—and the natural key from the source system. Since the same dimension can have many sources, a mapping table contains a natural key column for each of its sources.
Mapping tables can be equally effective if they are stored in a database or on the file system. The advantage of using a database for mapping tables is that you can utilize the database sequence generator to create new surrogate keys. And also, when indexed properly, mapping tables in a database are very efficient during key value lookups."
We have a requirement to implement cross-reference mapping tables with Natural and Surrogate Keys for each dimension table. These mappings tables will be populated automatically (only inserts) during the E-LT execution, right after inserting into the dimension table.
Someone have any idea on how to implement this on ODI?
Thanks,
Danilo

Hi,
first of all please avoid bolding something. After this according Kimball (if i remember well) is a 1:1 mapping, so no-surrogate key.
After that personally you could use Lookup Table
http://www.odigurus.com/2012/02/lookup-transformation-using-odi.html
or make a simple outer join filtering by your "Active_Flag" column (remember that this filter need to be inside your outer join).
Let us know
Francesco

Should surrogate key be numeric?

1. While on a data modleing course at Oracle, I was advised NOT to use numeric data types unless you needed to do numeric/arithmetic operations on the attribute. E.g. Even though an account_id is all digits it should still be declared as alpha numeric ( VARCHAR2) as it is NOT really a numeric. This makes sense.
I would like opnions on the above
2. If above advice is taken, then even a surrogate key should be alpha numeric since it does not require arithmetic/numeric computations. However, I have also heard that numerics are better than VARCHAR2 for joins. If this join performance advantage is true, then using a NUMBER data type for surrogate keys should be preferred over VARCHAR2? This overrides the advice in 1 above for join performance reasons.
I would like comments on 1 and 2.
Thanks
Edited by: user4900730 on Jun 16, 2010 12:19 PM

user4900730 wrote:
1. While on a data modleing course at Oracle, I was advised NOT to use numeric data types unless you needed to do numeric/arithmetic operations on the attribute. E.g. Even though an account_id is all digits it should still be declared as alpha numeric ( VARCHAR2) as it is NOT really a numeric. This makes sense.
I would like opnions on the above
2. If above advice is taken, then even a surrogate key should be alpha numeric since it does not require arithmetic/numeric computations. However, I have also heard that numerics are better than VARCHAR2 for joins. If this join performance advantage is true, then using a NUMBER data type for surrogate keys should be preferred over VARCHAR2? This overrides the advice in 1 above for join performance reasons.
I would like comments on 1 and 2.
Thanks
Edited by: user4900730 on Jun 16, 2010 12:19 PMSybrand gave a pretty good analysis of the performance issues. The instructor you mention just carried away with the idea of 'not everything that LOOKS like a number IS a number'. I think his point is valid for things like SSN and telephone numbers, etc. But my take is that if you are using a "number" for a surrogate key, then it probably really is a number - even if it is true you'd never do arithmetic on it. Comes back to the first lesson of being a dba (quoted in the first two minutes of the first Oracle class I took at their facility in Atalanta, back at version 7.3). "The answer to almost every question is 'it depends'"

Urgent expalantion about surrogate keys

Similar Messages

Maybe you are looking for