Unités fonctionnelles

Introduction

Il existe deux écoles de pensée concernant l'exécution de calculs dans votre base de données :les personnes qui pensent que c'est génial et les personnes qui se trompent. Cela ne veut pas dire que le monde des fonctions, des procédures stockées, des colonnes générées ou calculées et des déclencheurs n'est que rose et soleil ! Ces outils sont loin d'être infaillibles, et des implémentations irréfléchies peuvent mal fonctionner, traumatiser leurs mainteneurs, et plus encore, ce qui explique en partie l'existence d'une controverse.

Mais les bases de données sont, par définition, très efficaces pour traiter et manipuler les informations, et la plupart d'entre elles mettent le même contrôle et la même puissance à la disposition de leurs utilisateurs (SQLite et MS Access dans une moindre mesure). Les programmes de traitement de données externes démarrent sur le dos en ayant à extraire des informations de la base de données, souvent sur un réseau, avant de pouvoir faire quoi que ce soit. Et là où les programmes de bases de données peuvent tirer pleinement parti des opérations d'ensemble natives, de l'indexation, des tables temporaires et d'autres fruits d'un demi-siècle d'évolution des bases de données, les programmes externes de toute complexité ont tendance à impliquer un certain niveau de réinvention de la roue. Alors pourquoi ne pas faire fonctionner la base de données ?

Voici pourquoi vous pourriez ne pas voulez programmer votre base de données !

Les fonctionnalités de la base de données ont tendance à devenir invisibles, en particulier les déclencheurs. Cette faiblesse évolue approximativement avec la taille des équipes et/ou des applications qui interagissent avec la base de données, car moins de personnes se souviennent ou sont conscientes de la programmation dans la base de données. La documentation aide, mais dans une certaine mesure.
SQL est un langage spécialement conçu pour manipuler des ensembles de données. Il n'est pas particulièrement bon pour les choses qui ne manipulent pas des ensembles de données, et il est moins bon à mesure que ces autres choses deviennent compliquées.
Les capacités RDBMS et les dialectes SQL diffèrent. Les colonnes générées simples sont largement prises en charge, mais le portage d'une logique de base de données plus complexe vers d'autres magasins prend au minimum du temps et des efforts.
Les mises à niveau de schéma de base de données sont généralement plus difficiles que les mises à niveau d'application. La logique en évolution rapide est mieux conservée ailleurs, bien qu'elle puisse valoir la peine d'être réexaminée une fois que les choses se stabilisent.
La gestion des programmes de base de données n'est pas aussi simple qu'on pourrait l'espérer. De nombreux outils de migration de schéma ne font que peu ou rien pour l'organisation, ce qui entraîne des comparaisons tentaculaires et des révisions de code onéreuses (les graphiques de dépendance de sqitch et le remaniement d'objets individuels en font une exception notable, et migra cherche à contourner complètement le problème). Lors des tests, des frameworks tels que pgTAP et utPLSQL améliorent les tests d'intégration en boîte noire, mais représentent également un engagement de support et de maintenance supplémentaire.
Avec une base de code externe établie, tout changement structurel a tendance à être à la fois exigeant en efforts et risqué.

D'autre part, pour les tâches auxquelles il est adapté, SQL offre vitesse, concision, durabilité et la possibilité de "canoniser" les flux de travail automatisés. La modélisation des données ne se limite pas à fixer des entités comme des insectes sur du carton, et la distinction entre données en mouvement et données au repos est délicate. Le repos est un mouvement vraiment plus lent dans une qualité plus fine; les informations circulent toujours d'ici à là, et la programmabilité de la base de données est un outil puissant pour gérer et diriger ces flux.

Certains moteurs de base de données divisent la différence entre SQL et d'autres langages de programmation en prenant également en charge ces autres langages de programmation. SQL Server prend en charge les fonctions écrites dans n'importe quel langage .NET Framework; Oracle a des procédures stockées Java; PostgreSQL autorise les extensions avec C et est programmable par l'utilisateur en Python, Perl et Tcl, avec des plugins ajoutant des scripts shell, R, JavaScript, etc. Pour compléter les suspects habituels, c'est SQL ou rien pour MySQL et MariaDB, MS Access est seulement programmable en VBA, et SQLite n'est pas du tout programmable par l'utilisateur.

L'utilisation de langages non SQL est une option si SQL est inadéquat pour certaines tâches ou si vous souhaitez réutiliser un autre code, mais cela ne vous permettra pas de contourner les autres problèmes qui font de la programmation de base de données une arme à plusieurs tranchants. Au contraire, le recours à ceux-ci complique davantage le déploiement et l'interopérabilité. Caveat scriptor :que l'écrivain se méfie.

Fonctions vs Procédures

Un bloc nommé de SQL géré et exécuté dans la base de données semble ne pas être trop différent d'un autre, mais la plupart des SGBDR ont des fonctions distinctes et procédures stockées depuis des décennies.

Comme pour d'autres aspects de la mise en œuvre de la norme SQL, les détails exacts varient un peu d'un SGBDR à l'autre. En général :

Les fonctions ne peuvent pas contrôler les transactions.
Les fonctions renvoient des valeurs ; les procédures peuvent modifier les paramètres désignés OUT ou INOUT qui peut ensuite être lu dans le contexte d'appel, mais ne retourne jamais de résultat (sauf SQL Server).
Les fonctions sont appelées à partir d'instructions SQL pour effectuer certains travaux sur les enregistrements en cours de récupération ou de stockage, tandis que les procédures sont autonomes.

Plus précisément, MySQL interdit également la récursivité et certaines instructions SQL supplémentaires dans les fonctions. SQL Server interdit aux fonctions de modifier les données, d'exécuter du SQL dynamique et de gérer les erreurs. PostgreSQL n'a pas du tout séparé les procédures stockées des fonctions jusqu'en 2017 avec la version 11, de sorte que les fonctions PostgreSQL peuvent faire presque tout ce que les procédures peuvent faire, à l'exception du contrôle des transactions.

Alors, lequel utiliser quand ? Les fonctions sont mieux adaptées à la logique qui applique enregistrement par enregistrement au fur et à mesure que les données sont stockées et récupérées. Les flux de travail plus complexes qui sont invoqués par eux-mêmes et déplacent les données en interne sont préférables en tant que procédures.

Paramètres par défaut et génération

Même des calculs simples peuvent causer des problèmes s'ils sont effectués assez souvent ou s'il existe plusieurs implémentations concurrentes. Les opérations sur les valeurs d'une seule ligne - pensez à convertir entre les unités métriques et impériales, à multiplier un taux par les heures travaillées pour les sous-totaux de factures, à calculer la surface d'un polygone géographique - peuvent être déclarées dans une définition de table pour résoudre l'un ou l'autre problème :

CREATE TABLE pythag (  a INT NOT NULL,  b INT NOT NULL,  c DOUBLE PRECISION NOT NULL    GENERATED ALWAYS AS (sqrt(pow(a, 2) + pow(b, 2)))    STORED);

La plupart des SGBDR offrent le choix entre des colonnes générées "stockées" et "virtuelles". Dans le premier cas, la valeur est calculée et stockée lorsque la ligne est insérée ou mise à jour. C'est la seule option avec PostgreSQL, à partir de la version 12, et MS Access. Les colonnes virtuelles générées sont calculées lorsqu'elles sont interrogées comme dans les vues, elles ne prennent donc pas de place mais seront recalculées plus souvent. Les deux types sont étroitement limités :les valeurs ne peuvent pas dépendre d'informations extérieures à la ligne à laquelle elles appartiennent, elles ne peuvent pas être mises à jour et les SGBDR individuels peuvent avoir des limitations encore plus spécifiques. PostgreSQL, par exemple, interdit de partitionner une table sur une colonne générée.

Les colonnes générées sont un outil spécialisé. Le plus souvent, tout ce qui est nécessaire est une valeur par défaut au cas où une valeur n'est pas fournie lors de l'insertion. Des fonctions comme now() apparaissent fréquemment comme colonnes par défaut, mais la plupart des bases de données autorisent les fonctions personnalisées ainsi que les fonctions intégrées (à l'exception de MySQL, où seul current_timestamp peut être une valeur par défaut).

Prenons l'exemple assez sec mais simple d'un numéro de lot au format AAAAXXX, où les quatre premiers chiffres représentent l'année en cours et les trois derniers un compteur incrémental :le premier lot produit cette année est 2020001, le second 2020002, etc. . Il n'y a pas de type par défaut ou de fonction intégrée qui génère une valeur comme celle-ci, mais une fonction définie par l'utilisateur peut numéroter chaque lot lors de sa création :

CREATE SEQUENCE lot_counter;CREATE OR REPLACE FUNCTION next_lot_number () RETURNS TEXT AS $$BEGIN  RETURN date_part('year', now())::TEXT ||    lpad(nextval('lot_counter'::REGCLASS)::TEXT, 2, '0');END;$$LANGUAGE plpgsql;CREATE TABLE lots (  lot_number TEXT NOT NULL DEFAULT next_lot_number () PRIMARY KEY,  current_quantity INT NOT NULL DEFAULT 0,  target_quantity INT NOT NULL,  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),  completed_at TIMESTAMPTZ,  CHECK (target_quantity > 0));

Référencer les données dans les fonctions

L'approche séquentielle ci-dessus a une faiblesse importante (et au moins une moins importante ) :la nouvelle année arrive, lot_counter aura toujours la même valeur qu'au 31 décembre. Il existe cependant plusieurs façons de suivre le nombre de lots créés au cours d'une année, et en interrogeant les lots lui-même le next_lot_number La fonction peut garantir une valeur correcte après le roulement de l'année.

CREATE OR REPLACE FUNCTION next_lot_number () RETURNS TEXT AS $$BEGIN  RETURN (    SELECT date_part('year', now())::TEXT || lpad((count(*) + 1)::TEXT, 2, '0')    FROM lots    WHERE date_part('year', created_at) = date_part('year', now())  );END;$$LANGUAGE plpgsql;ALTER TABLE lots  ALTER COLUMN lot_number SET DEFAULT next_lot_number();

Flux de travail

Même une fonction à instruction unique présente un avantage crucial par rapport au code externe :l'exécution ne quitte jamais la sécurité des garanties ACID de la base de données. Comparer next_lot_number ci-dessus aux possibilités d'une application cliente ou même d'un processus manuel, exécutant une instruction SQL pour comptabiliser le nombre de lots cette année à ce jour suivi d'un second qui insère le nouveau lot. Si les commandes sont passées assez rapidement, le nombre de lots peut changer sous vous entre le comptage et l'insertion.

Les programmes stockés multi-instructions ouvrent un immense espace de possibilités, puisque SQL inclut tous les outils dont vous avez besoin pour écrire du code procédural, de la gestion des exceptions aux points de sauvegarde (c'est même Turing complet avec des fonctions de fenêtre et des expressions de table communes !). Des flux de travail de traitement de données entiers peuvent être exécutés dans la base de données, minimisant l'exposition à d'autres zones du système et éliminant les allers-retours chronophages entre la base de données et d'autres domaines.

Une grande partie de l'architecture logicielle en général consiste à gérer et à isoler la complexité, en l'empêchant de déborder au-delà des frontières entre les sous-systèmes. Si un flux de travail plus ou moins compliqué implique d'extraire des données dans un backend d'application, un script ou une tâche cron, de les assimiler et de les ajouter, et de stocker le résultat, il est temps de se demander ce qui nécessite vraiment de s'aventurer en dehors de la base de données.

Comme mentionné ci-dessus, il s'agit d'un domaine où les différences entre les saveurs RDBMS et les dialectes SQL sont mises en avant. Une fonction ou une procédure développée pour une base de données ne s'exécutera probablement pas sur une autre sans modifications, qu'il s'agisse de remplacer le TOP de SQL Server pour un LIMIT standard clause ou retravailler complètement la façon dont l'état temporaire est stocké dans une migration d'entreprise Oracle vers PostgreSQL. La canonisation de vos flux de travail dans SQL vous engage également dans votre plate-forme et votre dialecte actuels de manière plus approfondie que presque tout autre choix que vous pouvez faire.

Calculs dans les requêtes

Jusqu'à présent, nous avons envisagé d'utiliser des fonctions pour stocker et modifier des données, qu'elles soient liées à des définitions de table ou à la gestion de workflows multi-tables. Dans un sens, c'est l'utilisation la plus puissante à laquelle elles peuvent être destinées, mais les fonctions ont également leur place dans la récupération de données. De nombreux outils que vous utilisez peut-être déjà dans vos requêtes sont implémentés en tant que fonctions, à partir d'outils intégrés standard tels que count aux extensions telles que jsonb_build_object de Postgres , ST_SnapToGrid de PostGIS , et plus. Bien sûr, comme ceux-ci sont plus étroitement intégrés à la base de données elle-même, ils sont principalement écrits dans des langages autres que SQL (par exemple, C dans le cas de PostgreSQL et PostGIS).

Si vous avez souvent (ou pensez que vous pourriez avoir) besoin de récupérer des données, puis d'effectuer une opération sur chaque enregistrement avant qu'il ne soit vraiment prêts, envisagez plutôt de les transformer en sortant de la base de données ! Vous projetez un certain nombre de jours ouvrables à partir d'une date ? Générer un diff entre deux JSONB des champs? Pratiquement tout calcul qui dépend uniquement des informations que vous interrogez peut être effectué en SQL. Et ce qui est fait dans la base de données - tant qu'elle est accessible de manière cohérente - est canonique en ce qui concerne tout ce qui est construit au-dessus de la base de données.

Il faut le dire :si vous travaillez avec un backend d'application, sa boîte à outils d'accès aux données peut limiter la quantité de kilométrage que vous obtenez en augmentant les résultats des requêtes avec des fonctions. La plupart de ces bibliothèques peuvent exécuter du SQL arbitraire, mais celles qui génèrent des instructions SQL courantes basées sur des classes de modèles peuvent ou non autoriser la personnalisation de la requête SELECT listes. Les colonnes ou les vues générées peuvent être une réponse ici.

Déclencheurs et conséquences

Les fonctions et les procédures sont suffisamment controversées parmi les concepteurs et les utilisateurs de bases de données, mais les choses vraiment décoller avec des déclencheurs. Un déclencheur définit une action automatique, généralement une procédure (SQLite n'autorise qu'une seule instruction), à exécuter avant, après ou à la place d'une autre action.

L'action de lancement est généralement une insertion, une mise à jour ou une suppression dans une table, et la procédure de déclenchement peut généralement être configurée pour s'exécuter soit pour chaque enregistrement, soit pour l'instruction dans son ensemble. SQL Server autorise également les déclencheurs sur les vues pouvant être mises à jour, principalement pour appliquer des mesures de sécurité plus détaillées ; et lui, PostgreSQL et Oracle offrent tous une forme d'événement ou DDL déclencheur qui peut réagir aux changements dans la structure de la base de données.

Une utilisation courante à faible risque des déclencheurs est une contrainte extrêmement puissante empêchant le stockage de données non valides. Dans toutes les principales bases de données relationnelles, seules les clés primaires et étrangères et UNIQUE les contraintes peuvent évaluer des informations en dehors du dossier du candidat. Il n'est pas possible de déclarer dans une définition de table que, par exemple, seuls deux lots peuvent être créés en un mois - et la solution de base de données et de code la plus simple est vulnérable à une condition de concurrence similaire à celle de l'approche count-then-set pour lot_number au dessus de. Pour appliquer toute autre contrainte impliquant la table entière ou d'autres tables, vous avez besoin d'un déclencheur à voir en dehors du périmètre de la notice :

CREATE FUNCTION enforce_monthly_lot_limit () RETURNS TRIGGERAS $$DECLARE current_count BIGINT;BEGIN  SELECT count(*) INTO current_count  FROM lots  WHERE date_trunc('month', created_at) = date_trunc('month', NEW.created_at);  IF current_count >= 2 THEN    RAISE EXCEPTION 'Two lots already created this month';  END IF;  RETURN NEW;END;$$LANGUAGE plpgsql;CREATE TRIGGER monthly_lot_limitBEFORE INSERT ON lotsFOR EACH ROWEXECUTE PROCEDURE enforce_monthly_lot_limit();

Une fois que vous avez commencé à exécuter DML et en utilisant le contrôle de flux, c'est un saut et un saut pour lancer des séquences d'étapes beaucoup plus compliquées et élargir la portée pour inclure encore d'autres tables. Peut-être l'insertion d'un enregistrement dans lots lui-même peut être l'opération finale d'un déclencheur initié par une insertion dans les orders , sans utilisateur humain ou backend d'application autorisé à écrire dans lots directement. Ou comme items sont ajoutés à un lot, un déclencheur peut gérer la mise à jour de current_quantity , et démarrez un autre processus lorsqu'il atteint la target_quantity .

Les déclencheurs et les fonctions peuvent s'exécuter au niveau d'accès de leur définisseur (dans PostgreSQL, un SECURITY DEFINER déclaration à côté du LANGUAGE d'une fonction ), ce qui donne aux utilisateurs par ailleurs limités le pouvoir d'initier des processus plus étendus, et rend la validation et le test de ces processus d'autant plus importants.

La pile d'appels trigger-action-trigger-action peut devenir arbitrairement longue, bien qu'une véritable récursivité sous la forme de la modification des mêmes tables ou enregistrements plusieurs fois dans un tel flux soit illégale sur certaines plates-formes et plus généralement une mauvaise idée dans presque toutes les circonstances. L'imbrication des déclencheurs dépasse rapidement notre capacité à comprendre son étendue et ses effets. Les bases de données faisant un usage intensif de déclencheurs imbriqués commencent à dériver du domaine du compliqué vers celui du complexe, devenant difficiles ou impossibles à analyser, déboguer et prévoir.

Programmabilité pratique

Les calculs dans la base de données ne sont pas seulement plus rapides et plus concis :ils éliminent l'ambiguïté et établissent des normes. Les exemples ci-dessus évitent aux utilisateurs de la base de données de devoir calculer eux-mêmes les numéros de lot ou de s'inquiéter de créer accidentellement plus de lots qu'ils ne peuvent en gérer. Les développeurs d'applications, en particulier, ont souvent été formés pour considérer les bases de données comme un "stockage stupide", ne fournissant que structure et persistance, et peuvent donc se retrouver - ou pire, ne pas se rendre compte qu'ils le sont - articulant maladroitement en dehors de la base de données ce qu'ils pourraient faire plus efficacement en SQL.

La programmabilité est une caractéristique injustement négligée des bases de données relationnelles. Il existe des raisons de l'éviter et d'autres encore de limiter son utilisation, mais les fonctions, les procédures et les déclencheurs sont tous des outils puissants pour limiter la complexité que votre modèle de données impose aux systèmes dans lesquels il est intégré.