Home » RDBMS Server » Performance Tuning » how expensive is unique versus primary key in large table (9.2.0.1.0)
how expensive is unique versus primary key in large table [message #519588] Mon, 15 August 2011 06:08 Go to next message
OraFerro
Messages: 433
Registered: July 2011
Senior Member
Hi All,

I have two design alternatives and need to understand how expensive (speed) is one of them against the other for a medium size table (100K-200K records):

create table xyz
(
f1 number not null,
f2 varchar2(20) not null,
f3 number not null,
f4 varchar2(50),
f5 number(5),
primary key (f1, f2, f3) 
);

select * from xyz where f1 = 5 and f2 = 'adcf' and f3 = 454;


against the same select in:
create table abc
(
pk number(3) not null,
f1 number not null,
f2 varchar2(20) not null,
f3 number not null,
f4 varchar2(50),
f5 number(5),
primary key (pk) ,
unique (f1,f2,f3)
);

select * from abc where f1 = 5 and f2 = 'adcf' and f3 = 454;



the idea is to optimize the design by using a PK instead of the 3 keys and there is a debate that searching a unique index field(2nd scenario) is of the same speed than searching a PK field (1st scenario).
Re: how expensive is unique versus primary key in large table [message #519596 is a reply to message #519588] Mon, 15 August 2011 08:00 Go to previous messageGo to next message
joy_division
Messages: 4963
Registered: February 2005
Location: East Coast USA
Senior Member
Just do an explain plan and see what the results are.
Re: how expensive is unique versus primary key in large table [message #519601 is a reply to message #519596] Mon, 15 August 2011 08:27 Go to previous messageGo to next message
Michel Cadot
Messages: 68641
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
Read "Surrogate versus Natural Keys" on AskTom.

Regards
Michel
Re: how expensive is unique versus primary key in large table [message #519643 is a reply to message #519601] Tue, 16 August 2011 01:17 Go to previous messageGo to next message
rleishman
Messages: 3728
Registered: October 2005
Location: Melbourne, Australia
Senior Member
There is no performance difference whatsoever. Whether (F1,F2,F3) is a PK or UNIQUE constraint, it will still be supported by an identical index, and it is the index that does the work in a SELECT.

Ross Leishman
Re: how expensive is unique versus primary key in large table [message #519663 is a reply to message #519643] Tue, 16 August 2011 04:08 Go to previous messageGo to next message
OraFerro
Messages: 433
Registered: July 2011
Senior Member
The Article is usefull and I've read many like it. In fact I need an article that give an idea about the way index affect the search spead and hence the design decisions.
For example someone is claiming that if I have:

create table xyz
(
f1 number not null,
f2 varchar2(20) not null,
f3 number not null,
f4 varchar2(50),
f5 number(5),
primary key (f1, f2, f3) 
);



create table abc
(
pk number(3) not null,
f1 number not null,
f2 varchar2(20) not null,
f3 number not null,
f4 varchar2(50),
f5 number(5),
primary key (pk) ,
unique (f1,f2,f3)
);


Both below options of the same speed?
Option1 (passing single pk) the join 2 tables for select:
create table ref_fgh
(
pk number(2) primary key,
text varchar2(20),
fk_abc_pk,
FOREIGN KEY (fk_abc_pk) REFERENCES abc
);

select ref_fgh.*, f1,f2,f3
from ref_fgh, abc
where fk_abc_pk = abc.pk;


option 2: pass the composite key = select faster:

create table ref_fgh2
(
pk number(2) primary key,
text varchar2(20),
fk_xyz_f1,
fk_xyz_f2,
fk_xyz_f3,
FOREIGN KEY (fk_xyz_f1,fk_xyz_f2,fk_xyz_f3) REFERENCES xyz
);

select * from ref_fgh2;


So is it true that the 2 above scenarios have the same speed (my reference table size should be around 200k records)?
Re: how expensive is unique versus primary key in large table [message #520818 is a reply to message #519588] Wed, 24 August 2011 19:57 Go to previous message
Kevin Meade
Messages: 2103
Registered: December 1999
Location: Connecticut USA
Senior Member
The question is somewhat moot. A primary key constraint is not the same as a unique key constraint.

SQL> create table a
  2  (
  3     a integer primary key
  4  )
  5  /

Table created.

SQL> create table b
  2  (
  3     b integer unique
  4  )
  5  /

Table created.

SQL> insert into b values (null);

1 row created.

SQL> insert into a values (null);
insert into a values (null)
                      *
ERROR at line 1:
ORA-01400: cannot insert NULL into ("KEVIN"."A"."A")


So do you use PK or UK because one is faster than the other?

Wrong Thinking.

Right thinking is you design your database correctly by observing proper constraint usage in all your tables.


If that means you need PK for a table then you use PK, if it means you need UK then you use UK. It is all about your design goals, not the need for some barely detectable speed difference.


Ramifications of Database Design Choices
Changing your original question into something a little different, design is a big thing and is much deeper than many people think. Consider these facts and questions:

F1) a single column primary key means a single column foreign key in child tables.
F2) Oracle Forms the developer tool generates constraints to enforce referential integrity if you want it to.

Q1) what kind of trigger is generated by Oracle Forms if your referential constraint is a single column constraint?
Q2) what kind of trigger is generated by Oracle Forms if your referential constraint is a multi-column constraint?

A1) item level validation trigger
A2) row level validation trigger

Your choice of something as seemingly simple as do I use a single column key or a multi-column key means that the behavior of the code that will be written against your database will differ depending upon what you choose. Your end-user experience changes slightly because of your design choice. As does the work your developers must do to write apps against your database.

Going a bit further, now that you know this, would you let this knowledge change your choices in your key designs? Hmm... some might, particularly those who would be anticipating a large Oracle Forms in-house developed Application System and who have recently attended a manager's conference stressing the value of immediate feedback of errors in front end systems as a way to increase end-user efficiency. I am not advocating for or against it, just pointing out how database design goes way beyond just data models and indeed clearly affects application design and development.


Overall PK is Better
But more related to your original question, since PK does not allow nulls and UK does, there can be query optimizations done by the CBO which likes columns defined as NOT NULL for various reasons. Your example does not show this because you use the same nullability regardless of if you define your constraint as PK or UK. But none-the-less, this can become meaningful. Consider the optimization called DUNSEL JOIN REMOVAL added in 10g and enhanced in 11g. To the extent that PK increases joins across columns known to be NOT NULL, the incidence of DUNSEL JOIN REMOVAL may be higher and thus result in faster query executions. Indeed, this can play a huge role in reporting systems and warehouse systems that opt for a surrogate key design strategy because it opens up the oportunity for generalized reporting objects that do not suffer from performance slow downs associated with lots of needless joins defined in views where for a particular query against the view, one or more of the tables and their associated joins don't contribute to the requested output. But I talk about some obscure stuff here. Suffice it to say PK will be faster OVERALL for the database for various reasons.

But I re-iterate, PK != UK so you should not be choosing based on speed.

Good luck, Kevin

[Updated on: Wed, 24 August 2011 20:05]

Report message to a moderator

Previous Topic: application performance
Next Topic: Insert / Update Performance due to Triggers (merged 2)
Goto Forum:
  


Current Time: Sat Apr 20 00:13:22 CDT 2024