What is the diffrence between Row id and primary key ?

Question

dear all
my question is about creating materialized views parameters (With Rowid and
With Primary kry)
my master table contains a primary key
and i created my materialized view as follow:
CREATE MATERIALIZED VIEW LV_BULLETIN_MV
TABLESPACE USERS
NOCACHE
LOGGING
NOCOMPRESS
NOPARALLEL
REFRESH FAST ON DEMAND
WITH PRIMARY KEY
AS
SELECT
BCODE ID, BTYPE BTYPE_ID,
BDATE THE_DATE,SYMBOL_CODE STOCK_CODE,
BHEAD DESC_E, BHEADARB DESC_A,
BMSG TEXT_E, BMSGARB TEXT_A,
BURL URL, BTIME THE_TIME
FROM BULLETIN@egid_sefit;
I need to know is there a diffrence between using (with row id) and (with primary key) on the performance of the query?

Answer 1

Hi again,
fast refreshing complex views based on rowids, according to the previous subject.
(You're example shows that) are not possible.
Complex remote (replication) snapshots cannot be based on Rowid too.
for 10.1
http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10759/statements_6002.htm#sthref5054
for 10.2
http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_6002.htm#sthref6873
So I guess (didn't check it) that this applies ONLY to replication snapshots.
This is not documented clearly though (documentation bug ?!)
Documentation states that the following is generally not possible with Rowid MVIEWS:
Distinct or aggregate functions
GROUP BY or CONNECT BY clauses
Subqueries
Joins
Set operations
Rowid materialized views are not eligible for fast refresh after a master table reorganization until a complete refresh has been performed.
The main purpose of my statements was to try to give a few tips how to avoid common problems with this complex subject, like for example: being able to CREATE an MVIEW with fast refresh clause does not really guarantee that it will refresh fast in the long run (reorganisation, partition changes) if ROWID based, further the rowid mviews have limitations according to the documentation (no group by, no connect by, link see above) plus fast refresh means only to use filter columnns of the mview logs, plus for aggregates you need additional count (*) pseudo columns.
kind regards
Karsten