|
|
|
Re: Performance impact by using Number/Char column as primary key [message #608664 is a reply to message #608663] |
Fri, 21 February 2014 15:42 |
|
BlackSwan
Messages: 26766 Registered: January 2009 Location: SoCal
|
Senior Member |
|
|
harpreetsinghkup wrote on Fri, 21 February 2014 13:34is this make diffrence?
PK Column a varchar2 (50) will be slower then PK column B varchar2 (10) ?
are you unwilling or incapable to actually run benchmark tests & compare the results?
Do you realize & understand that I/O occurs at the data BLOCK level & most often multiple blocks in single I/O request?
It appears that you suffer from Compulsive Tuning Disorder.
>I am an Oracle Certified Professional having more then 8 year of experience of using Oracle.
Then why are you asking such novice questions?
[Updated on: Fri, 21 February 2014 15:45] Report message to a moderator
|
|
|
Re: Performance impact by using Number/Char column as primary key [message #608668 is a reply to message #608664] |
Fri, 21 February 2014 20:02 |
|
Kevin Meade
Messages: 2103 Registered: December 1999 Location: Connecticut USA
|
Senior Member |
|
|
Attributes should be typed based on their true nature, not based on the idea that one type may be better than another performance wise. With that in mind, the definition of your columns should be whatever data type the column holds.
Is the data character data or number data? type it accordingly.
There was in fact a time early on when data types and column ordering etc. made a small difference in performance in certain situations.
There are possibly still such situations but there are two things to note about it:
1. if the difference exists in a specific situation it will likely be so small you cannot measure it esaily
2. Oracle ehancements over the years have lead to intelligence in the database that automatically addresses many of these types of concerns so doing anything about it for any "trick" the database now does automatically is a waste of time. The great example of this is "order of predicates in the where clause".
Which all takes us back to what I said before. Data types should be based on the data, not on some idea of potentially better performance, even if it exists.
Good luck. Kevin
|
|
|