On Tue, 25 Aug 2015 18:57:28 -0400, Neil Tiffin <neilt@neiltiffin.com>
wrote:
>
>> 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 not possible to write a
> reliable database change script. Dump and restore maintain the name. Of
> course every project has periodic scripts that need to run, so these
> objects would, if they are dropped or manipulated in the script, have to
> be manually 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 referred to 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 original table definitions that
> could be problematic. But I always have used the current definitions
> not the original and those can be exported with the current names.
>
> It just seems like busy work to me, but I would love to be enlightened.
>
> Neil
I suspect he's alluding to migration scripts from an ORM - which are
typically scaffolded with boilerplate, but almost invariably need to be
tweaked in order to effect the desired changes in the database..
- John