Bonsoir,
Dans l'idéal je voudrais recueillir quelques avis pour savoir si je suis de bonnes pratiques car, dans mon périple de programmation from scratch pour un backend, en tant qu'amateur dans mon coin, parfois je me sens vraiment comme un navigateur en solitaire...
Il s'agit ici d'une optimisation pour une base de donnée sous PostgreSQL, plus spécifiquement il s'agit du remplissage automatique des colonnes en lien avec une date de révision :
Dans un premier temps j'ai pensé remplir le champ "_date_modified" par une requête SQL à partir de l'application, par exemple, sur un point de terminaison :
J'ai eu un petit soucis de formatage de la date, mais avant de corriger le bug et d'avancer plus avant, je me suis dit :
Bingo, avec un trigger :
Et comme la table "__account" n'est pas la seule concernée par ce type de colonne (que, heureusement, par esprit maniaque j'ai dénommé de la même manière partout) je peux appeler la fonction pour tout le monde, bien que cela soit un peu répétitif :
Pour revenir sur la question initiale : y-a-t-il de meilleures manières de procéder ou c'est OK ? Puis-je faire encore des optimisations de code sur cette fonctionnalité ?
Dans l'idéal je voudrais recueillir quelques avis pour savoir si je suis de bonnes pratiques car, dans mon périple de programmation from scratch pour un backend, en tant qu'amateur dans mon coin, parfois je me sens vraiment comme un navigateur en solitaire...
Il s'agit ici d'une optimisation pour une base de donnée sous PostgreSQL, plus spécifiquement il s'agit du remplissage automatique des colonnes en lien avec une date de révision :
CREATE TABLE __account (
_id INT GENERATED BY DEFAULT AS IDENTITY,
[...]
_date_created TIMESTAMP DEFAULT CURRENT_TIMESTAMP, -- date de création
_date_modified TIMESTAMP NULL, -- date de révision
[...]
PRIMARY KEY (_id),
FOREIGN KEY (_author_id) REFERENCES __person(_id) ON DELETE SET NULL -- CONSTRAINT __post__person_fkey
);Dans un premier temps j'ai pensé remplir le champ "_date_modified" par une requête SQL à partir de l'application, par exemple, sur un point de terminaison :
UPDATE __account SET _date_modified = CURRENT_TIMESTAMP, _role_name = $2, _language = $3, _media_id = $4 WHERE _id = $1J'ai eu un petit soucis de formatage de la date, mais avant de corriger le bug et d'avancer plus avant, je me suis dit :
a écrit :
Si ça se trouve, puisque j'arrive à remplir automatiquement la colonne "_date_created" sans passer par l'application, il doit bien y avoir un moyen de faire la même chose pour compléter "_date_modified" seulement sur un UPDATE"...
Bingo, avec un trigger :
CREATE OR REPLACE FUNCTION update_date_modified()
RETURNS TRIGGER AS $$
BEGIN
NEW._date_modified = CURRENT_TIMESTAMP; -- Mettre à jour _date_modified avec le timestamp actuel
RETURN NEW;
END;
$$ LANGUAGE plpgsql;Et comme la table "__account" n'est pas la seule concernée par ce type de colonne (que, heureusement, par esprit maniaque j'ai dénommé de la même manière partout) je peux appeler la fonction pour tout le monde, bien que cela soit un peu répétitif :
CREATE TRIGGER update_date_modified_trigger__account
BEFORE UPDATE ON __account
FOR EACH ROW
EXECUTE FUNCTION update_date_modified();
CREATE TRIGGER update_date_modified_trigger__post
BEFORE UPDATE ON __post
FOR EACH ROW
EXECUTE FUNCTION update_date_modified();
CREATE TRIGGER update_date_modified_trigger__media
BEFORE UPDATE ON __media
FOR EACH ROW
EXECUTE FUNCTION update_date_modified();
CREATE TRIGGER update_date_modified_trigger__comment
BEFORE UPDATE ON __comment
FOR EACH ROW
EXECUTE FUNCTION update_date_modified();Pour revenir sur la question initiale : y-a-t-il de meilleures manières de procéder ou c'est OK ? Puis-je faire encore des optimisations de code sur cette fonctionnalité ?
)
)