Link to home
Start Free TrialLog in
Avatar of Prisoner362670
Prisoner362670

asked on

Changing database structure by Adding Primary Key field SQL 11g

Greetings Experts -

Today a general discussion question.

I have inherited a database an Oracle 11g database with NO primary key field.  
Instead an external identifier with a not null constraint was used to relate all the tables, run the forms and update the records.  

As is the fate of all external identifiers, it is now being superseded and will no longer be available to my inherited database.  Even better--not every record in the inherited database will be assigned a new external identifier.

Ideally, I would like to migrate the old external identifier into a new field, and modify its former field to a primary key field with an autonumber sequence.  By reusing the field I hope to avoid having to rewrite all of the tables/queries and forms.

I am unclear as to the method and timing of updating the related tables.  Should I create a new temporary field in the 'base' table so that I maintain integrity while I update the related child tables?  Other pitfalls?  Is this an accepted approach?  Are there others?

CongoGrey
Avatar of MikeOM_DBA
MikeOM_DBA
Flag of United States of America image

Can you post a sample of the table definition?
Avatar of Prisoner362670
Prisoner362670

ASKER

Sure Mike - Sorry for the delayed response as I have been ill.

Table1: Demography
ColName             IDNO                                    FName  
DataType            VARCHAR2 (7 Byte)            VARCHAR2(20 Byte)
Nullable              NO                                           Yes
DataDefault        (null)                                          (null)
PrimaryKey          (null)                                         (null)                                            
ConstraintType    Check (idno is not null)
Status                    Enabled                                  
Deferrable            Not Deferrable
IndexName            (null)      

Table2: RelatedTable1

ColName                    IDNO
DataType                    VARCHAR2 (7 Byte)          
Nullable                       No
DataDefault                (null)
PrimaryKey                 (null)

Let me know if you need additional information
Sorry, but I am still not sure what you mean by "an external identifier"?
What is the source and how is the local table populated with this value?

Why not preserve the current values of said identifier converting it to primary key and just code a function to generate the future values for that key?
The 'external identifier' is an id number generated by another database.  Certain demographic information from that database is imported into the Oracle 11g database using the SQL loader utility.  Imports may be new records or updates to existing records.

The 'external identifier' will change both size and datatype in the external database within a few months.  
There are several tacks I could take which is why this is a discussion question.

Your suggestion is novel to me.  Let me restate it to make sure that I understand:  modify the idno field to primary key, retain the current values in idno and set a sequence function to assign values to all new records.
Create a new field to hold the new external identifier and use this value to locate records for update.

Another twist on the same suggestion: If I updated the field/datatype in the Oracle 11g demographic table with a primary key constraint and updated the old identifier to the new identifier (because I need to perform updates using the external database), how would I change the old identifier written in the related tables in Oracle 11g to the new identifier?
ASKER CERTIFIED SOLUTION
Avatar of MikeOM_DBA
MikeOM_DBA
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi Mike - sounds like a plan!  I'll try it in my test environment between this afternoon and Monday afternoon and let you know how it turns out.
However, in the meantime I'm going to accept your solution.  It was the 'no need to modify related tables' that did it for me.
I have yet to test this solution but overall it seems sound and prudent.  I will write back after test.