Cet article explique comment configurer WordPress avec MariaDB et Traefik en utilisant des réseaux Docker séparés pour améliorer la sécurité et faciliter la duplication de sites. L’article détaille la création d’une architecture où chaque site WordPress et sa base de données sont isolés dans leur propre réseau privé, inaccessible depuis internet, tandis que Traefik gère le routage et les certificats SSL automatiquement via Let’s Encrypt. Le tutoriel propose une configuration étape par étape : installation de Traefik avec SSL, création de réseaux Docker dédiés, déploiement d’un premier site WordPress, puis duplication aisée pour ajouter d’autres sites. Les avantages soulignés sont la sécurité renforcée, la simplicité de gestion et la possibilité d’ajouter facilement de nouveaux sites. L’auteur évoque aussi des pistes d’amélioration, comme l’automatisation des sauvegardes des bases de données. Idéal pour qui veut héberger plusieurs sites WordPress de manière sécurisée et scalable.
Symfony, Doctrine et les triggers SQL sont souvent en tension : les triggers offrent une robustesse et une atomicité inégalées pour des logiques critiques (audit, validation, compteurs), mais leur gestion dans un projet Symfony reste complexe, car leur code SQL est souvent perdu dans des migrations ou invisible pour les développeurs. Le Trigger Mapping Bundle propose une solution élégante en permettant de déclarer les triggers directement dans les entités via des attributs PHP, les rendant ainsi visibles, versionnables et gérables comme le reste du code. Le bundle offre des commandes pour intégrer, créer, valider et mettre à jour les triggers, tout en facilitant la transition depuis un projet existant. L’objectif ? Réconcilier la puissance des triggers SQL avec la philosophie de Symfony et Doctrine, en choisissant le bon outil selon le besoin : trigger pour l’intégrité des données, listener Doctrine pour la logique applicative. Une approche qui réduit la dette technique et améliore la maintenabilité.
Un analyste confronté à une requête lente sur une table de 150 millions de transactions (2 minutes d’exécution, parfois des timeouts) a optimisé son code en utilisant une CTE (Common Table Expression) avec WITH. Au lieu de joindre d’abord les tables puis de filtrer, la CTE filtre d’abord les transactions récentes (20M de lignes au lieu de 150M), réduisant le temps d’exécution de 127 à 11 secondes. En allant plus loin et en agrégeant directement dans la CTE, il a même descendu ce temps à moins de 6 secondes. La clé ? Filtrer tôt pour alléger la charge de jointure, clarifier la logique, et exploiter les optimisations des moteurs modernes (PostgreSQL 12+, BigQuery). Attention toutefois : les performances varient selon le SGBD (risque de matérialisation en tables temporaires sous MySQL ancien). Une leçon simple : une requête bien structurée = des gains de performance majeurs.
Tout est dans le titre
Tout est dans le titre
Présentation de "database-anonymizer"
Tout est dans le titre
Tout est dans le titre
Un super outil pour MySQL / MariaDB en ligne de commande (meilleur que la commande "mysql" de base) Il existe aussi en version PostgreSQL
Un article pense bête
Tout est dans le titre
Tout est dans le titre, sauf que ça marche pour d'autres distributions
Tout est dans le titre
Tout est dans le titre... mais ça marche sous d'autres distributions
Ça existe depuis la norme SQL:2003... et c'est partiellement implémenté dans la plupart des SGBD
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre