Josh Berkus wrote:
>Aasmund,
>
> Thank you for the clarification. Now that I know what you are doing, I
>went through exactly the same thing about a year ago ... which is how we
>discovered some additional problems with using OIDs in database design.
>I was trying to spare you the same dead end.
>
>>>If your problem is that you want to update VIEWs and aren't sure
>>>
>>what the
>>
>>>PK for the view is, could you follow a standard like this:
>>>
>>>CREATE TABLE person (social_security CHAR(9), full_name TEXT);
>>>
>>>CREATE VIEW pers_view AS select social_security AS primkey,
>>> social_security,
>>> full_name);
>>>
>>>and know that you can always find the "primkey" field in the view as one
>>>
>>>to use in where clauses for updates?
>>>
>
>This is more-or-less a correct approach. As it does not address the
>issue of different data types, let me tell you what I did:
>
>Each significant data table contains one column, the first column,
>called "usq", for "universal sequence". This usq field may or may not
>be the primary key for the table, but does have a unique index. The usq
>is populated by a single sequence "universal_sq" which is shared between
>tables, thus allowing all tables usq uniqueness between them.
>
>This strategy has allowed me to write a number of functions which are
>table-agnostic, needing only the usq to do their job (such as a function
>that creates modification hisotry).
>
>-Josh Berkus
>
Hi Josh!
Once you have your usq, how do you get more info about that row?
How do you know which table it came from?
Thanks
--
Dado Feigenblatt Wild Brain, Inc.
Technical Director (415) 216-2053
dado@wildbrain.com San Francisco, CA.
