Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l7LH8-0006qi-0W for pgsql-admin@arkaria.postgresql.org; Wed, 03 Feb 2021 16:45:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1l7LH6-00047h-Mo for pgsql-admin@arkaria.postgresql.org; Wed, 03 Feb 2021 16:45:04 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l7LH6-00047Z-D7 for pgsql-admin@lists.postgresql.org; Wed, 03 Feb 2021 16:45:04 +0000 Received: from lana.depesz.com ([88.198.49.178] helo=depesz.com) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l7LH3-0005li-PG for pgsql-admin@lists.postgresql.org; Wed, 03 Feb 2021 16:45:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=depesz.com; s=20170201; h=In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Reply-To:Message-ID:Subject:Cc:To:Sender:From:Date: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=x4OxpSQ3gXNOBZcBRYz6m5zTb4SMoTnUpckBYU1luPM=; b=bxBLjHisEjbivwvdoyOxwU5ie1 cdQrYnnzdXFnOZc04bMWjv9hlIGJgmjSzQQEMlGy/JA0jJM1zhzbuNb/EPQAlyN6Oc2zHKgdkzZ+E P1BuDc3pOr7Repx2OVunWxUosQ841K8r4DVE2flY6p/OyQzAt3Sjs5swafWel6D7buJ8=; Received: from lana.depesz.com ([88.198.49.178] helo=depesz.com) by depesz.com with esmtpa (Exim 4.92) (envelope-from ) id 1l7LH1-0007dm-L5; Wed, 03 Feb 2021 17:44:59 +0100 Date: Wed, 3 Feb 2021 17:44:59 +0100 From: hubert depesz lubaczewski Sender: depesz@depesz.com To: "David G. Johnston" Cc: Mai Peng , Pgsql-admin Subject: Re: Design database Message-ID: <20210203164459.GA17357@depesz.com> Reply-To: depesz@depesz.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Feb 03, 2021 at 08:35:41AM -0700, David G. Johnston wrote: > On Wed, Feb 3, 2021 at 8:23 AM Mai Peng <[1]maily.peng@webedia-group.com> wrote: > > Hello, > > I’ve got a table name publication, and another table named publication_item. > Each publication_item is linked to a publication by publication_id. > How could I add a constraint that check each publication has one or more publication_item when a tuple is inserted ? > I don’t want to store items in the same table as publication because we could have 1-> n items. > > [2]https://www.postgresql.org/docs/current/tutorial-fk.html I don't think it helps. Fkey can check that publication_item contains valid publication_id, but doesn't ensure that every publication has at least one item. As for the problem of OP, I think this describes working solution: https://www.depesz.com/2017/07/03/how-to-make-sure-there-is-always-at-least-one-sub-record/ Best regards, depesz