Re: PostgreSQL Developer Best Practices

From: Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
To: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: PostgreSQL Developer Best Practices
Date: 2015-08-26 13:47:45
Message-ID: 20150826134744.GC27302@hermes.hilbert.loc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Aug 26, 2015 at 09:04:08AM -0400, John Turner 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.
>
> I suspect he's alluding to migration scripts from an ORM

Not in the least.

https://github.com/ncqgm/gnumed/tree/master/gnumed/gnumed/server/sql

Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Kaushal Shriyan 2015-08-26 15:29:22 Point in time recovery
Previous Message Igor Neyman 2015-08-26 13:45:53 Re: PostgreSQL Developer Best Practices