5.8 KiB
Alternative Spider 2.0-Lite per database dimostrativi con Evidence
Verifica del 27 settembre 2026. Il criterio è complessità del database e qualità della documentazione di dominio da curare in ThothII, non prestazioni sul benchmark né numero di domande pubblicate. Nessun database è stato installato.
Metodo e limiti
Ispezionati DDL, metadati per tabella e documenti ufficiali in
Spider2, revisione osservata
cafb867313aab4e674652054198f383cf4018943. I conteggi sotto sono delle tabelle
dichiarate nei DDL e delle colonne nei JSON, non un'ispezione dei file SQLite.
La procedura ufficiale
offre un archivio dei database locali. I database cloud seguono un percorso diverso.
Candidati locali
| Database | Tabelle / colonne nei metadati | Materiale semantico riscontrato | Valutazione |
|---|---|---|---|
E_commerce |
11 / 70 | Documento RFM; documentazione originale Olist da integrare | Il più coerente dei candidati Lite esaminati per una demo aziendale, ma complessità media |
complex_oracle |
10 / 140 | Proiezione vendite e conversioni valutarie; dizionario originale Oracle SH da confrontare | Buon caso analitico, meno esteso relazionalmente |
oracle_sql |
38 / 124 | Documento sul rapporto vendite/media mobile e finestre temporali | Molte tabelle, documentazione semantica allegata troppo parziale |
AdventureWorks |
13 / 120 | Documentazione originale Microsoft, da riallineare al sottoinsieme Spider | Non confondere questo estratto con l'intero AdventureWorks |
Conteggi ricavati dai DDL e JSON ufficiali: E_commerce,
complex_oracle,
oracle_sql,
AdventureWorks.
In tutti i JSON di questi quattro candidati, gli array description controllati
sono vuoti: tipi e righe di esempio non costituiscono da soli un dizionario di dominio.
E_commerce
Comprende ordini, righe d'ordine, pagamenti, recensioni, prodotti, clienti, venditori, geolocalizzazione e lead. Il documento RFM definisce recency, frequency, monetary e undici segmenti con regole di assegnazione. Sono fonti concrete di formule e regole, da rivedere e collegare allo schema.
La fonte originale Olist
fornisce CSV e spiega una distinzione utile: customer_id identifica il cliente
nel contesto dell'ordine, mentre customer_unique_id permette di riconoscere acquisti
ripetuti della stessa persona. La distribuzione Olist di base contiene nove file;
non equivale automaticamente alle undici tabelle Spider, che includono i lead.
complex_oracle
Il documento allegato descrive proiezione mensile delle vendite, crescita rispetto all'anno precedente, conversione in USD e gestione di cambi mancanti. Lo schema ha vendite e costi con dimensioni prodotto, cliente, calendario, canale, promozione e geografia.
Nomi e struttura sono riconducibili al Sales History di Oracle.
Il suo script sh_create.sql contiene 88 commenti COMMENT ON TABLE/COLUMN e la
distribuzione comprende CSV. È materiale aggiuntivo utile, ma ogni corrispondenza
con lo schema Spider, incluse estensioni come currency, va verificata: non si
deve importare la documentazione dell'originale come se descrivesse automaticamente
ogni adattamento Spider.
oracle_sql
Le tabelle coprono magazzino, ordini, confezioni annidate, vendite mensili e altri sottodomini eterogenei. Il documento di calcolo tratta tre aspetti: rapporto fra vendite e media mobile centrata, finestre di dodici mesi e limiti temporali per evitare effetti ai bordi. Questo non documenta in modo completo le altre parti del database: sconsigliato come scelta basata sulla sola abbondanza di tabelle.
Alternativa cloud con documentazione più ricca
ga4 offre tre documenti complementari: dizionario degli eventi,
dimensioni e metriche
e categorie delle pagine.
Coprono campi annidati, classificazione dei canali e regole di interpretazione;
sono più vicini al requisito semantico. Tuttavia la
distribuzione Spider è BigQuery:
molte tabelle sono partizioni giornaliere dello stesso schema logico. Il conteggio
fisico non è una misura utile di complessità relazionale. Esportazione locale e
adattamento PostgreSQL sarebbero lavoro aggiuntivo, non un semplice import SQLite.
Esito
Nessuno dei quattro candidati SQLite esaminati combina da solo schema molto esteso
e documentazione di dominio completa già pronta. Per cercare una scelta più forte,
confrontare con i progetti Spider 2.0-DBT nella ricerca separata
2026-09-27-spider2-dbt-evidence-candidates.md. I modelli documentati di dbt non
vanno confusi con tabelle fisiche già presenti, né le librerie di utility con Evidence.