RE: Best way to make a table of non-unique rows, unique?

I'm pretty sure it's in April 2006 newsletter (link is further down on that
web page). Here is a direct link:

http://www.centerfieldtechnology.com/publications/archive/April%202006.pdf

I think in your case ROWID might work as well, since you don't really care
what the unique identifier is.

HTH, Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com


-----Original Message-----
Subject: RE: Best way to make a table of non-unique rows, unique?

Elvis,

I've looked on Page 8 of the article your link took me to and could not find
anything about the subjects you wrote about. I even did a search on auto
and increment with no results. Page 8 seems to be talking about Visual
Explain. While I found the Visual Explain article helpful, I found nothing
on the Auto-increment and Identity column.

I was thinking about the topics you mentioned but couldn't remember in which
manual I could find all the info. So, anything to which you can point me
would be helpful.

My thinking was to put triggers on the vendor's tables I need. These
triggers would be looking for INSERTs, UPDATEs or DELETEs. When those
were detected, I would copy the row to a similar table with all the same
columns but with the addition of the columns you mention and/or a
datetimestamp column and an "operation" column where I would insert an "I",
"U" or "D" for the operation that caused the insert in the "similar" table.
Then I could put a unique index on the columns you mentioned and/or my
datetimestamp and operation column which would make each row unique. I
realize this would, in essence, create rows of "history" but I think this
is a faster solution than complex programming and if the users know about
the data when they create their queries they can take that into account and
either disregard whatever rows they don't need or take advantage of the
history if that better suits them. In any case, I would add these new
"similar" tables to the remote journal u!
sed by DataPropagator in the DW LPAR and DataPropagator would be satisfied
with a unique index and my entire project won't be side-tracked because of
OLD, OLD, bad design wherein the advantages of a relational database were
ignored in favor of OLD, OLD application development methodologies.

I very much appreciate everyone's input.

Thanks,

Dave