Sujet : data-modelling
-
Concevoir une table de séries temporelles en ajout seul dans PostgreSQL
Stocker les mesures dans une table partitionnée par plage temporelle avec timestamptz, une clé composite de série et de temps, des index adaptés au schéma de requête (B-tree par série, BRIN pour les scans temporels sur toute la table) et une rétention mise en œuvre en détachant puis en supprimant des partitions plutôt qu'avec DELETE ; ces choix découlent du fait que les lignes arrivent dans l'ordre chronologique et repartent par tranches temporelles entières.
-
Dimensions à évolution lente : écraser, ajouter une ligne ou ajouter une colonne
Lorsqu'un attribut de dimension change (un client déménage, un produit est reclassé), le type 1 écrase et perd l'historique, le type 2 ajoute une nouvelle ligne avec des dates d'effet et d'expiration et un indicateur de ligne courante sous une nouvelle clé de substitution, et le type 3 conserve l'ancienne valeur dans une colonne supplémentaire. Les outils d'instantané implémentent le type 2 en comparant un horodatage de mise à jour ou un ensemble de colonnes à chaque exécution.
-
Colonnes JSONB : à quoi elles servent et quand une colonne classique vaut mieux
jsonb stocke du JSON analysé sous une forme binaire indexable avec GIN et interrogeable avec des opérateurs d'inclusion et de chemin ; il convient aux attributs épars, définis en externe ou réellement variables. Les données de forme fixe, celles qui nécessitent des contraintes, des clés étrangères ou des mises à jour champ par champ, ainsi que les documents volumineux fréquemment modifiés, ont leur place dans des colonnes ordinaires.
-
Les enregistrements de consentement et de préférence comme données : ce qui a été choisi, quand et par quelle voie
Modéliser les choix d'une personne sous forme d'événements en ajout seul (sujet, finalité, choix, moment, source, version du texte), avec une vue d'état courant dérivée que chaque consommateur lit au moment de l'usage ; un booléen sur la ligne utilisateur ne peut répondre ni à ce qui avait été accepté au moment d'une action donnée, ni à la question de savoir quels utilisateurs un bug de bannière a touchés.
-
La minimisation des données comme discipline de schéma et de journalisation
Ne stocker que les données personnelles dont une fonctionnalité a besoin, à la précision la plus grossière qui la satisfait, et tenir les identifiants hors des journaux en n'autorisant explicitement que certains champs ; chaque colonne, chaque champ de journal et chaque magasin dérivé qui porte des données personnelles est une décision de conception dotée d'une finalité, d'un responsable et d'une échéance, et non un choix par défaut.
-
Suppression logique (soft delete) contre tables d'archivage
Une suppression logique conserve la ligne avec un marqueur deleted_at, si bien que chaque requête doit la filtrer et chaque contrainte d'unicité doit devenir un index partiel ; une table d'archivage déplace la ligne hors de la table active, de sorte que les requêtes actives restent simples et que l'historique réside en un seul endroit. Le choix dépend de qui lit les données supprimées et à quelle fréquence, et doit être porté par les contraintes et les vues plutôt que par chaque requête.
-
Normaliser jusqu'à la troisième forme normale et choisir quand dénormaliser
Les formes normales éliminent les groupes répétitifs et les faits stockés à plus d'un endroit ; la troisième forme normale signifie que chaque colonne non clé dépend de la clé et de rien d'autre. Normaliser par défaut les données transactionnelles, et ne dénormaliser que dans des colonnes dérivées, nommées comme telles, dont la source de vérité reste normalisée.
-
Contraintes déclaratives dans PostgreSQL : CHECK, UNIQUE et clés étrangères avec ON DELETE
Les contraintes font en sorte que la base de données rejette les états invalides pour tout auteur d'écriture, pas seulement pour l'application : CHECK pour des règles par ligne, NOT NULL pour les valeurs requises, UNIQUE pour l'identité, et des clés étrangères avec une action ON DELETE explicite. Choisir l'action référentielle et indexer la colonne référençante sont les deux décisions le plus souvent omises.
-
Les bases du schéma en étoile : faits, dimensions et déclaration du grain
Un schéma en étoile stocke les mesures dans des tables de faits et le contexte descriptif dans des tables de dimensions reliées par des clés ; la conception commence par la déclaration du grain, ce que représente une ligne de la table de faits, car chaque mesure et chaque dimension doit lui être cohérente. Les mesures totalement additives se somment selon n'importe quelle dimension, les mesures semi-additives ne se somment pas selon le temps, et les ratios doivent être stockés sous la forme de leurs composants.
-
Pseudonymisation et anonymisation comme techniques d'ingénierie
La pseudonymisation remplace les identifiants directs par des jetons tout en conservant un moyen de revenir en arrière (une clé ou une table de correspondance), et laisse un enregistrement par personne ; l'anonymisation vise à supprimer l'association entre les enregistrements et les personnes, pour tout le monde. Utiliser un HMAC à clé propre à chaque finalité pour les pseudonymes, et traiter une table pseudonymisée comme des données personnelles où subsistent des quasi-identifiants.
-
Colonnes d'identité, séquences et pourquoi les identifiants générés comportent des trous
Les colonnes d'identité sont le moyen standard de numéroter automatiquement les lignes dans PostgreSQL ; elles puisent dans une séquence dont les valeurs sont distribuées en dehors du contrôle transactionnel, de sorte que les annulations (rollback), les plantages, la mise en cache et les insertions avec ON CONFLICT laissent des trous. Les trous sont normaux ; une numérotation sans trou nécessite un compteur distinct et sérialisé.
Lisible par machine : JSON