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 |
|
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 #519663 is a reply to message #519643] |
Tue, 16 August 2011 04:08 |
|
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 |
|
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
|
|
|
Goto Forum:
Current Time: Fri Nov 22 01:12:02 CST 2024
|