Contraintes de clé étrangère dans les relations plusieurs-à-plusieurs

C'est demander des ennuis. Vous continuerez à rencontrer des incompatibilités mineures. Ou même pas les remarquer jusqu'à bien plus tard, lorsque le mal est fait. Ne le faites pas. Utilisez également PostgreSQL localement. Il est disponible gratuitement pour la plupart des systèmes d'exploitation. Pour quelqu'un impliqué dans un "projet de cours sur les bases de données", c'est une folie surprenante. Connexe :

• Solution Ruby générique pour SQLite3 "LIKE" ou PostgreSQL "ILIKE" ?

Autre conseil :

• Comme @Priidu mentionné dans les commentaires , vos contraintes de clé étrangère sont inversées. Ce n'est pas à débattre, ils ont tout simplement tort .

• Dans PostgreSQL, utilisez un serial ou IDENTITY colonne (Postgres 10+) au lieu de SQLite AUTOINCREMENT . Voir :

  • Colonne de tableau d'incrémentation automatique

• Utilisez timestamp (ou timestamptz ) au lieu de datetime .

• N'utilisez pas d'identificateurs à casse mixte.

  • Exception de déclenchement PostgreSQL

  • Les noms de colonnes PostgreSQL sont-ils sensibles à la casse ?

• N'utilisez pas de noms de colonne non descriptifs comme id . Déjà. C'est un anti-modèle introduit par le middleware et les ORM. Lorsque vous rejoignez quelques tables, vous vous retrouvez avec plusieurs colonnes du nom id . C'est activement blessant.

• Il existe de nombreux styles de dénomination, mais la plupart s'accordent à dire qu'il est préférable d'utiliser des termes au singulier comme noms de table. C'est plus court et au moins aussi intuitif/logique. label , pas les labels .

Tout assemblé, cela pourrait ressembler à ceci :

CREATE TABLE IF NOT EXISTS post (
   post_id   serial PRIMARY KEY
 , author_id integer
 , title     text
 , content   text
 , image_url text
 , date      timestamp
);

CREATE TABLE IF NOT EXISTS label (
   label_id  serial PRIMARY KEY
 , name      text UNIQUE
);

CREATE TABLE IF NOT EXISTS label_post(
    post_id  integer REFERENCES post(post_id) ON UPDATE CASCADE ON DELETE CASCADE
  , label_id integer REFERENCES label(label_id) ON UPDATE CASCADE ON DELETE CASCADE
  , PRIMARY KEY (post_id, label_id)
);

Déclencheur

Pour supprimer les libellés inutilisés, mettez en œuvre un déclencheur . Je fournis une autre version car je ne suis pas satisfait de celui fourni par @Priidu :

CREATE OR REPLACE FUNCTION f_trg_kill_orphaned_label() 
  RETURNS trigger
  LANGUAGE plpgsql AS
$func$
BEGIN
   DELETE FROM label l
   WHERE  l.label_id = OLD.label_id
   AND    NOT EXISTS (
      SELECT 1 FROM label_post lp
      WHERE  lp.label_id = OLD.label_id
      );
END
$func$;

• La fonction de déclenchement doit être créé avant le déclencheur .

• Un simple DELETE la commande peut faire le travail. Aucune deuxième requête nécessaire - en particulier pas de count(*) . EXISTS est moins cher.

• Les guillemets simples autour du nom de la langue sont tolérés, mais c'est vraiment un identifiant, alors omettez simplement le non-sens :LANGUAGE plpgsql

CREATE TRIGGER label_post_delaft_kill_orphaned_label
AFTER DELETE ON label_post
FOR EACH ROW EXECUTE PROCEDURE f_trg_kill_orphaned_label();

Il n'y a pas de CREATE OR REPLACE TRIGGER dans PostgreSQL, pour le moment. Juste CREATE TRIGGER .