📏 Règles de contraintes de données (DB + Django)

[maxcorbeau]

📏 Règles de contraintes de données (DB + Django)

Carte Notion : Qualité de données: ajout de contraintes (URL, email) au niveau DB avec CHECK

• 💡 quoi: proposition de décision sur l'utilisation de contraintes SQL en base
• 🎯 pourquoi: voir section 🎯 Pourquoi cette proposition? pour plus d'infos, en court:
  • 🥇 Améliorer la qualité des données: en empêchant l’insertion de mauvaises données en base
  • ☮️ / ⏰ Au delà de la qualité, améliorer la confiance et réduire le temps perdu en bug/support: car même si un problème n’affecte qu’un % réduit de la donnée totale, il est suffisant pour engendrer bugs et autres problèmes chronophages
• 🤔 comment: en priorisant les problèmes de qualité de données par ROI (retour sur investissement: ratio de valeur métier vs. effort technique) et en implémentant les contraintes champ par champ au fur et à mesure

📜 Contenu de la proposition

⭐ Principes mis en avant

• ✋ Prévenir > guérir: mieux vaut investir de l’ingénérie en amont pour guarantir la qualité des données plutôt que de dépenser du temps métier (nettoyage) + ingénérie à postériori (ex: [Tâche de backlog pour un utilitaire de correction des données en masse](https://www.notion.so/tude-Specs-co-t-d-une-UI-de-bulk-sur-Django-Admin-1346523d57d7803598aedc04207111f6?pvs=21))
• ⭐ Soucis de qualité > performance: dans un contexte où:

  • 🔢 On a très peut de données et donc on peut ajouter des contraintes

    • 1 an de vie de startup et on à < 400K acteurs affichés
    • avec un déploiement décent, une base PostgreSQL peut gérer des millions d’entrées sans problème

  • 📖 L’utilisation principale des données est la lecture via la carte où les contraintes d’écriture ne s’appliquent pas

  • 🚀 Les contraintes vont peut être même amener des gains de performances en supprimant du bruit (ex: table d’affichage qui ne contient que ~80% d’acteurs affichés)

    

• 🧱 Base de données = dernier rempart qu'on la mauvaise donnée dont on ne peut jamais guarantir à 100% qu'elle passera toujours par nos modèles de validation Django

🎯 Pourquoi cette proposition?

• 🥇 Améliorer la qualité des données: en empêchant tout simplement l’insertion de mauvaises de données en base, quelles que soient les méthodes utilisées
• ☮️ / ⏰ Au delà de la qualité, améliorer la confiance et réduire le temps perdu en bug/support: car même si un problème n’affecte qu’un % réduit de la donnée totale, il est suffisant pour engendre les problèmes suivants:
  • Utilisateurs grand public qui constatent des erreurs et soumettent des demandes de correction via le formulaire
  • Equipe métier qui doit aller vérifier si la donnée est bien erronée en base où si c’est un problème d’affichage
  • Equipe data engineering: mauvaises données qui viennent polluer nos pipelines, causant leur échec ou pire des erreurs silencieuses plus difficiles à déceler et résoudre, ex clustering:
    • pourquoi ces acteurs on été clusterisés ensemble?
      • à cause du score de similarité siret
    • pourquoi on à des sirets à 0000000000?
      • parce qu’elles sont permises en base

⚖️ Options évaluées

Critère	OPTION 1: Status-quo	OPTION 2: Faire passer tout le traitement de donnée par modèles Django	OPTION 3: Prioriser l'usage des modèles Django MAIS ajouter des contraintes DB en filet de sécurité
🎥 Réalisme du scénario	🟢 élevé (réalité aujourd’hui)	🔴 faible: dans la pratique on en est pas capable (il y a des tâches telles correctifs SQL ou peut être plus tard vues SQL à la dbt)	🟢 élevé si effectué étape par étape (càd champ par champ, voir section “Example de mise en oeuvre”)
⭐ Qualité des données	🟡 moyenne	🟢 élevée	🟢 élevée
📖 Performance lecture	🟡 Potentiellement impactée par le bruit mais aussi négigeable vu volume	🟡 Potentiellement impactée par le bruit mais aussi négigeable vu volume	🟢 Maximale (tables ne contiennent que 100% de données valides)
✍🏻 Performance écriture	🟡 Potentiellement impactée par le bruit mais aussi négigeable vu volume	🟡 Potentiellement impactée par le bruit mais aussi négigeable vu volume	🟡 Potentiellement impactée par les contraintes mais aussi négigeable vu volume
🧊 Devoir gérer des tâches de contraintes SQL	🟢 non	🟢 non	🟡 oui, après cela ce fait très bien depuis des décénies

💡 Décision préconisée

Pour le traitement des données on décide de:

• Prioriser l’utilisation des modèles Django y compris pour les pipelines qui tournent hors Django (ex: airflow)
• Rajouter des contraintes DB comme filet de sécurité au cas où:
  • les modèles Django seraient contournés
  • les modèles Django ne remplieraient pas leur rôle (bug de logique ou logique manquante)
• Rajouter les contraintes champ par champ, suivant les priorités et définitions métier

🚧 Exemple de mise en oeuvre

On priorise les problèmes de qualité de données par ROI (retour sur investissement: ratio de valeur métier vs. effort technique)

• Disons que le 1er point identifié est la présence de 20% d’acteurs non-actifs dans la table d’affichage

• (5 min) On fait un SQL correctif pour supprimer les nons actifs de la table

• (5 min) On ajoute la contrainte suivante:

  ALTER TABLE qfdmo_displayedacteur
  ADD CONSTRAINT statut_actif_uniquement
  CHECK (statut = 'ACTIF');

  ⇒ Et voilà, plus d’acteurs non-actifs 🙂 La prochaine fois que quelqu’un / qu’une pipeline essaye d’ajouter des acteurs non-actifs à la table d’affichage l’opération sera interdite, la tâche échouera, on aura identifié le coupable et on pourra résoudre le problème à la source

• On répète les étapes ci-dessus, champ par champ en fonction du ROI, en étalant les tâches au besoin (ex: chaque semaine on gère 1 contrainte)

• Par exemple on se dit qu’un code postal doit être normalisé à 5 chiffres:

  ALTER TABLE qfdmo_displayedacteur
  ADD CONSTRAINT code_postal_a_5_chiffres
  CHECK (email ~ '^[0-9]{5}$')