database redesign
my response hasn't shown up on
http://postgresql.1045698.n5.nabble.com/upgrading-to-9-3-td5777291.html so
trying again. sorry if both show up.
anyway, on database reorganization - is it recommended to group all
sequences and domains under one public schema? or is a sequence tied to a
table as its counter?
what are some replication choices for x64 systems since slony is not an
option?
On 11/8/2013 11:44 AM, zach cruise wrote:
my response hasn't shown up on
http://postgresql.1045698.n5.nabble.com/upgrading-to-9-3-td5777291.html so
trying again. sorry if both show up.anyway, on database reorganization - is it recommended to group all
sequences and domains under one public schema? or is a sequence tied
to a table as its counter?
I would keep sequences in the same schema as the related table. anything
else is chaotic. if a domain is used by all the schemas, then putting
it in public makes sense, otherwise, if its just used by one schema, it
should logically be part of that schema.
what are some replication choices for x64 systems since slony is not
an option?
the built in streaming replication is the usual first choice.
--
john r pierce 37N 122W
somewhere on the middle of the left coast
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, Nov 8, 2013 at 12:09 PM, John R Pierce <pierce@hogranch.com> wrote:
On 11/8/2013 11:44 AM, zach cruise wrote:
anyway, on database reorganization - is it recommended to group all
sequences and domains under one public schema? or is a sequence tied to a
table as its counter?I would keep sequences in the same schema as the related table. anything
else is chaotic. if a domain is used by all the schemas, then putting it
in public makes sense, otherwise, if its just used by one schema, it should
logically be part of that schema.
I would also like to suggest using serial/bigserial types instead of
integer/bigint + sequence. This will automatically create a sequence
that is depended on the table.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray.ru@gmail.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general