Re: PostgreSQL Developer Best Practices
| От | Neil Tiffin |
|---|---|
| Тема | Re: PostgreSQL Developer Best Practices |
| Дата | |
| Msg-id | E29AEDCE-624F-4BF9-9019-3CAA75D174DA@neiltiffin.com обсуждение исходный текст |
| Ответ на | Re: PostgreSQL Developer Best Practices ("Karsten Hilbert" <Karsten.Hilbert@gmx.net>) |
| Ответы |
Re: PostgreSQL Developer Best Practices
|
| Список | pgsql-general |
> 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
В списке pgsql-general по дате отправления: