[Résolu] SQL : tables identiques ?

CREATE TABLE __article (
  _id                   INT               GENERATED BY DEFAULT AS IDENTITY,
  _name                 VARCHAR(255)      NOT NULL,                         -- titre
  _alternative_headline VARCHAR(255)      NULL,                             -- titre secondaire
  _slug                 VARCHAR(255)      UNIQUE NOT NULL,                  -- slug basé sur le titre
  _content              TEXT              NULL,                             -- contenu
  _created_at           TIMESTAMP         DEFAULT CURRENT_TIMESTAMP,        -- date de création
  _modified_at          TIMESTAMP         NULL,                             -- date de révision
  _type                 VARCHAR(30)       NULL,                             -- article, page, etc...
  _description          VARCHAR(1000)     NULL,                             -- contenu utilisé pour la balise meta description ; pas de limitation car les politiques des moteurs de recherche changent dans le temps.
  _author_id            INT               NOT NULL,                         -- créateur du post (contributeur principal)
  _status               SMALLINT          DEFAULT 1,                        -- brouillon = 0, publié = 1, privé = 2, refusé = 3, corbeille = 9
  _is_readable          BOOLEAN           DEFAULT true,                     -- l'article peut être lu
  _is_commentable       BOOLEAN           DEFAULT false,                    -- les commentaires sont activés
  _is_visible_comments  BOOLEAN           DEFAULT true,                     -- les commentaires sont visibles
  _add                  JSONB             NULL,                             -- permet de stocker des données en vue des microdonnées (clef-valeurs sur une convention schema.org)
  PRIMARY KEY (_id),
  FOREIGN KEY (_author_id) REFERENCES __person(_id) ON DELETE SET NULL,     -- CONSTRAINT __article__person_fkey
  CONSTRAINT lowercase_and_hyphens_only CHECK (_slug ~ '^[a-z0-9-]+$')      -- Minuscules anglaises, chiffres et tirets uniquement
);

Tony Monast a écrit :
Bonjour,

Je suis de l'avis contraire. Les articles sont une chose, et les sujets du forum autre chose.

Pour le moment, ils partagent les mêmes attributs, mais tôt ou tard, les articles et les sujets du forum vont évoluer avec le CMS et tu finiras par devoir ajouter certains attributs aux articles spécifiquement ou aux sujets du forum, et tu vas te retrouver avec des colonnes inutiles pour l'un ou l'autre.

Cela va aussi rendre plus complexe les requêtes SQL, car tu devras toujours filtrer les données selon le type d'entité et/ou les jointures ne seront pas les mêmes.

Je n'arrive plus à mettre la main dessus, mais j'avais lu un article qu'il était préférable de créer des tables différentes pour chaque entité, plutôt qu'essayer de toutes les mettre ensemble dans la même table, même si leurs attributs étaient identiques.

Tony Monast a écrit :
Bonjour,

Je suis de l'avis contraire. Les articles sont une chose, et les sujets du forum autre chose.

Pour le moment, ils partagent les mêmes attributs, mais tôt ou tard, les articles et les sujets du forum vont évoluer avec le CMS et tu finiras par devoir ajouter certains attributs aux articles spécifiquement ou aux sujets du forum, et tu vas te retrouver avec des colonnes inutiles pour l'un ou l'autre.

Cela va aussi rendre plus complexe les requêtes SQL, car tu devras toujours filtrer les données selon le type d'entité et/ou les jointures ne seront pas les mêmes.

Je n'arrive plus à mettre la main dessus, mais j'avais lu un article qu'il était préférable de créer des tables différentes pour chaque entité, plutôt qu'essayer de toutes les mettre ensemble dans la même table, même si leurs attributs étaient identiques.

Olivier C a écrit :
Il pourrait bien y avoir une notion d'héritage, mais il me semble qu'imiter l'orienté objet pour le SQL n'est pas une voie à suivre.

Olivier C a écrit :

Édit : reste sauf quand même la remarque de comar91 sur le rapport performances/volumétrie. Ça vaudrait peut-être le coup, effectivement, que les articles soit très rapidement disponibles. Un forum c'est moins important. À voir. En tous les cas, Jencal, l'approche que tu as suggéré et très intéressante et mérite d'être considérée.

Jencal a écrit :

Tu dis "les requêtes SQL d'interrogation des données resteront les mêmes.", je rebondis, attention l'héritage ne fonctionne pas avec INSERT

Tony Monast a écrit :
Voici l'article que j'ai trouvé : https://docs.postgresql.fr/16/ddl-inherit.html Le seul exemple d'INSERT qui est donné et qui ne fonctionne pas, c'est parce que la requête tente d'insérer dans la table parente une donnée dans une colonne qui n'existe que dans la table enfant.

CREATE TABLE parent (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE child1 (
    child1_specific_column VARCHAR(50)
) INHERITS (parent);

CREATE TABLE child2 (
    child2_specific_column INTEGER
) INHERITS (parent);

-- Insertion de données dans les tables filles
INSERT INTO child1 (name, child1_specific_column) VALUES ('Alice', 'Data1');
INSERT INTO child2 (name, child2_specific_column) VALUES ('Bob', 123);