Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fz7mw-0003JA-SW for pgsql-admin@arkaria.postgresql.org; Sun, 09 Sep 2018 22:02:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fz7mu-00066V-Le for pgsql-admin@arkaria.postgresql.org; Sun, 09 Sep 2018 22:02:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fz7mu-00066O-C9 for pgsql-admin@lists.postgresql.org; Sun, 09 Sep 2018 22:02:36 +0000 Received: from mail-pl1-x641.google.com ([2607:f8b0:4864:20::641]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fz7mn-0003Lx-23 for pgsql-admin@postgresql.org; Sun, 09 Sep 2018 22:02:35 +0000 Received: by mail-pl1-x641.google.com with SMTP id g23-v6so8793891plq.9 for ; Sun, 09 Sep 2018 15:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version:content-transfer-encoding; bh=MrzeZsYfVqjkY96I46FN4YKAcuWzJ7sxJ31af3+AVlQ=; b=mI2PAfRTunaknYMI2pxqhI5OWR7A4FqZOhqi+zbpN5K1PgIeTKluIZqJlpieCQXAes DXi5We+gweVx+5/MqfVoWnaVNBXolgho+DcKSpHcq5SuqQBJK8Xa4hBV1ZwIEs/Y6AN0 s3a5Wb2o7kED5uThrU6tCPIMOKe9gahq3+OA7KD61aZ+9ApPCRB18zIvk966m5pih+NW /KfGv6rqTItbUv2gMjtjXz7g1KeiGBfuuGycPuWXhtsxyOTV1UsTuEYnny77+rpliuDh mdzwk+Q/YepR8KpxLOz8ocnJFiP97DwEdELabfgPny45M2ekrA2V9WjpcOc+ejPa4672 PuSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version:content-transfer-encoding; bh=MrzeZsYfVqjkY96I46FN4YKAcuWzJ7sxJ31af3+AVlQ=; b=Ko0JfSzrzx6fvwHfecrj21F7J/UngRA3LT0/L4KGJYEvzLpfXvPE1voDE9rRjR2AzV /vNuNjbG0R7nADVr/7P9EC82NQMrGjn3yqqbpnvAWiHT2tFcGw6Iz1JyaQgPUm5kbSXt 4OC0A7/Sw2SH5r0LrGbQFKoaO08praw/UfCYuvrjfg7QgklPikPnO4U0GxKFoqFii2nq wZFvgF3XKASHo9POMTB/E+3yf6O7M0HAh5VuEDJs8FPDpzPX7917XWi4H+d7jQpQ9NNa 9Y9oaShq3mRuMvNsRpMBmHUNl7Nr5ZbPS//jTFO4wHY2pLqZJRwkqCxdtgBJAiCyoytA 9QeQ== X-Gm-Message-State: APzg51CjI6RlDv/lN0oyCVb/oMzimPUZuNYR9FlUIR/9XKRwgkSSsda0 nX+NhB9Fz2mKWJruJy0ERulFhPOe X-Google-Smtp-Source: ANB0VdZ0zdzO96u4YsZoWXg9vaXrI/ZlaZuQNhcXtgTOYUpPjUzqPn2zFAs1CP2PY3BMdAM74ON4lQ== X-Received: by 2002:a17:902:6bc8:: with SMTP id m8-v6mr18877128plt.162.1536530545180; Sun, 09 Sep 2018 15:02:25 -0700 (PDT) Received: from tim-desktop (2001-44b8-31f2-bb00-3d9d-0624-cec8-4928.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:3d9d:624:cec8:4928]) by smtp.gmail.com with ESMTPSA id b64-v6sm18507044pfg.66.2018.09.09.15.02.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 09 Sep 2018 15:02:24 -0700 (PDT) References: <30A5D829-58E2-4934-9C93-25968D05183B@foursource.pt> User-agent: mu4e 0.9.18; emacs 26.1 From: Tim Cross To: Joao Ribeiro Cc: pgsql-admin@postgresql.org Subject: Re: Schema's vs Single Database with prefix on tables In-reply-to: <30A5D829-58E2-4934-9C93-25968D05183B@foursource.pt> Date: Mon, 10 Sep 2018 08:02:19 +1000 Message-ID: <871sa25nys.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Joao Ribeiro writes: > Hello, > > We are using Postgres and we are with a issue. We have splited our tables= by domain and > each domain has a separated database, but we are trying to change it to a= single database > model. We have two options, create the same database in a single schema a= nd add a prefix > on each database domain or create a schema for each database (we have abo= ut 15 > different models). In this approach we still want to do some joins and ot= her queries cross > schema, but we don=E2=80=99t know what would be the best approach :) Coul= d you help us to know > what would be the best approach ? > > * having just one database with one schema and all domain databases with = a prefix > * having a schema for each domain (15 domains) with the domain databases = (+/ 20 tables) > (knowing that we do cross schema queries) > > _____ It is probably just a matter of taste to some extent. I personally would favour separate schemas over tables in same schema with prefixes because I think that gives you more flexibility i.e. easier to select all the data associated with a domain as it is all in one schema. I also think it is easier to define security roles on a per schema basis rather than complex roles in the same schema, especially if you add new objects etc. Auditing is also less complex. There are no issues with cross-schema queries/joins etc apart from having to include the schema name in the query. Some people don't like this because you have to type more and have a longer search_path, but if the alternative is table prefixes, the amount of typing is similar anyway. Essentially, the schema gives you a predefined unit which many tools/commands understand. If everything is in the same schema, then you will often need to replicate some level of this functionality yourself and then ensure it is maintained. Extent to which this has an impact really depends on your use case.=20 Tim --=20 Tim Cross