Posted by Brian Cryer on 06/28/05 19:16

"debian mojo" <debian_mojo@yahoo.com> wrote in message
news:aeawe.4$jU.2182@news.uswest.net...
> Thanks Erland,
> That's true that moving away from the problem is not a solution. But
> you see that the database i'm talking about is a 24 x 7 database, and
> i'm not pretty sure how apps that are using this db.
>
> If i do pri keys to the tables, is there any possibility that the apps
> may suffer is some way.
>
> I do agree that in most of the cases there's no harm.... but you see
> the database is a production one and i'm really paranoid about it's
> safety!
>
> I hope you understand!
>
> BTW, your advice was an eye-opener for me.
>
> So what do you suggest? what are the other things i should take care
> of before adding the pri keys?
>
> Debian
>
>
> *** Sent via Developersdex http://www.developersdex.com ***

Don't make changes to a live production database unless you have tested it
first and are comfortable about the changes you are going to make. You NEED
primary keys, but don't make the assumption that adding a new primary key
won't break one of your applications. If all you are doing is redefining an
existing unique index as a primary key then that shouldn't hurt anything,
but if you are adding a new field as a primary (default NEWID as per
Erland's suggestion [a very good suggestion by the way]) then that does have
the potential to break something - I think its only likely to break badly
written code, but the potential is there, so test it first.

Take a copy, add your primary keys to that and then run through the whole
range of applications and ensure that everything works as you expect. Only
then, once you are entirely satisfied, introduce the changes to the live
database and even then be sure that you can roll your changes back if it all
goes horribly wrong.

Brian.

www.cryer.co.uk/brian

[Back to original message]