> On Aug 25, 2015, at 1:38 PM, Karsten Hilbert <Karsten.Hilbert@gmx.net> wrote:
>
>> In most cases developers don’t care about index, unique, foreign key, or primary key names (from a coding
standpoint)
>
> Until the day they’d like to write a reliable database change script.
Not sure I understand. Once the object is created the name is set, it does not change, so I don’t understand why it is
notpossible to write a reliable database change script. Dump and restore maintain the name. Of course every project
hasperiodic scripts that need to run, so these objects would, if they are dropped or manipulated in the script, have to
bemanually named, especially during development since the whole database might be dropped and recreated multiple times.
My original comment included that situation. My projects typically have many, many objects that once created are not
referredto again, unless a DBA is doing some tuning or troubleshooting. In that case, the DBA just looks up the name.
I can see if say 2 years later you want to create a development database from the original SQL that generated the
originaltable definitions that could be problematic. But I always have used the current definitions not the original
andthose can be exported with the current names.
It just seems like busy work to me, but I would love to be enlightened.
Neil