APAndrea Pellizzari
Andrea Pellizzari — Diario — markdown editor
← diario/
2026-04-24-diagnostica-codice-non-pubblicato.md
content//diario//2026-04-24-diagnostica-codice-non-pubblicato.md
1
2
3
4
5
6
7
---
title: "Diagnostica 'perché questo codice non è pubblicato': una query grossa batte dieci query puntuali"
date: 2026-04-24
tags: ["python", "sql-server", "diagnostica"]
excerpt: "Un articolo sparito dal sito è la domanda settimanale in ufficio. Ho scritto un tool Python+tkinter che risponde in due secondi con una query SQL e due chiamate FTP — e mi ha costretto a leggere come si deve le viste dell'ERP aziendale."
slug: 2026-04-24-diagnostica-codice-non-pubblicato
---

Diagnostica 'perché questo codice non è pubblicato': una query grossa batte dieci query puntuali

Un articolo sparito dal sito è la domanda settimanale in ufficio. Ho scritto un tool Python+tkinter che risponde in due secondi con una query SQL e due chiamate FTP — e mi ha costretto a leggere come si deve le viste dell'ERP aziendale.

Un dialogo settimanale in ufficio: "questo articolo non è sul sito, perché?". Prima di questo mese rispondevo aprendo cinque pagine del gestionale, un client SQL, un FTP client e un browser. Venti minuti di archeologia per scoprire che mancava un flag in una scheda di caratteristiche, o che l'immagine sul server aveva un underscore di troppo.

Ho scritto un tool che lo fa in due secondi.

Nove check in una singola query

La tentazione iniziale era ovvia: per ogni controllo una query. Un'interrogazione sull'anagrafica, una sul listino, una sulla scheda posizionamento, una sulle caratteristiche, e così via. Undici controlli → undici round-trip al database. Per un codice.

La cosa utile è che tutte le informazioni che mi servivano stavano in quattro tabelle collegate da una chiave articolo. Un LEFT JOIN fatto bene le tira fuori in una sola chiamata:

sql = """
SELECT a.codice, a.flag_cancellato, a.flag_annullato,
       l.prg_listini,
       p.flag_annullato AS posiz_annullato,
       c.flag_a_catalogo, c.brand_a, c.brand_b
FROM articoli a
LEFT JOIN listini l          ON a.codice = l.codice
LEFT JOIN posizionamento p   ON a.codice = p.codice
LEFT JOIN caratteristiche c  ON a.codice = c.codice
WHERE a.codice LIKE ?
"""

Con il LIKE accetta anche un prefisso: cerco ABC00245 e mi tira fuori tutti i figli in un colpo. Dieci codici da diagnosticare diventano una query, non sessanta.

LEFT JOIN non esclude, RIGHT JOIN sì

Il giorno prima avevo dedicato un'ora a una ricognizione delle viste SQL del catalogo. Sono viste scritte negli anni da persone diverse, una sopra l'altra — v_dati_catalogo che chiama v_dati_normalizzati che chiama v_export_finale. Un albero che una GUI diagnostica può anche ignorare, ma per capirne i filtri occorre leggerle.

La lezione più utile di quella ricognizione è banale ma sistematica: un LEFT JOIN non esclude righe, un RIGHT JOIN o un INNER JOIN. In mezzo alle viste c'era un RIGHT JOIN sulla scheda caratteristiche che era la vera spina dorsale del catalogo: se un articolo non aveva un record in quella tabella, spariva silenziosamente tre livelli di vista più sopra. Il diagnostico deve elencare quella join come check dedicato, non come dettaglio tecnico.

FTP per bypassare la cache HTTP

Per capire se un articolo è stato realmente pubblicato, il tool scarica il manifesto JSON del sito. Il file è servito via HTTPS ma l'hosting ha una cache aggressiva: a volte risponde con una copia di dieci minuti prima, falsando il verdetto. Lo scarico via FTP: niente cache, niente CAPTCHA, e come bonus ottengo anche la lista delle immagini nella directory del catalogo per l'ultimo check.

Il risultato finale è una GUI tkinter con un campo di input e quattro possibili verdetti: PUBBLICATO, NON_PUBBLICABILE, IN_ATTESA_EXPORT, FILIERA_OK_SENZA_IMMAGINE. Distribuita come EXE da 17 MB, gira sui PC dell'ufficio con un doppio click.

Il tool non è elegante. Ma ha trasformato una domanda da venti minuti di lavoro in un doppio click.

● Markdown41 lines410 words2 mintags: #python #sql-server #diagnostica
UTF-8LF.mdx