--
Regards,
Krishnakant Mane,
Project Founder and Leader,
GNUKhata <https://gnukhata.in/>
//(Opensource Accounting, Billing and Inventory Management Software)//
You might think about adding the new UUID column and use the existing
primary key to inform the updates in dependent tables. Then remove
the old PK column and constraint followed by promoting the UUID to
primary key. This could be safely scripted and applied to all
instances of your data.
That said, this is only truly necessary of you have production
databases to worry about.
Thanks a million, this is the most logical and safe way.
yes I have a lot of production databases to worry about.
I am only confused about what you mean by "use the existing primary
key to inform the updates in dependent tables."
Are you refering to a cascading effect?
If yes then does it mean I first program my upgrade script to manually
go through all new uuid keys and update the same in the depending
tables with reference to the old primary key working as foreign key in
those tables?
It occurs to me you will also need to "duplicate" the columns in which
you have foreign keys. How many tables are there in the affected
schemata and what is the size? Pretty sure you will have to go off-line
to perform this sort of transition. Nearly everything will be touched.
--
Regards,
Krishnakant Mane,
Project Founder and Leader,
GNUKhata <https://gnukhata.in/>
//(Opensource Accounting, Billing and Inventory Management Software)//