# 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](https://github.com/xlang-ai/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](https://github.com/xlang-ai/Spider2/blob/main/spider2-lite/README.md)
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](https://github.com/xlang-ai/Spider2/tree/main/spider2-lite/resource/databases/sqlite/E_commerce),
[complex_oracle](https://github.com/xlang-ai/Spider2/tree/main/spider2-lite/resource/databases/sqlite/complex_oracle),
[oracle_sql](https://github.com/xlang-ai/Spider2/tree/main/spider2-lite/resource/databases/sqlite/oracle_sql),
[AdventureWorks](https://github.com/xlang-ai/Spider2/tree/main/spider2-lite/resource/databases/sqlite/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](https://github.com/xlang-ai/Spider2/blob/main/spider2-lite/resource/documents/RFM.md)
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](https://www.kaggle.com/olistbr/brazilian-ecommerce/metadata)
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](https://github.com/xlang-ai/Spider2/blob/main/spider2-lite/resource/documents/projection_calculation.md)
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](https://github.com/oracle-samples/db-sample-schemas/tree/main/sales_history).
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](https://github.com/xlang-ai/Spider2/blob/main/spider2-lite/resource/documents/calculation_method.md)
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](https://github.com/xlang-ai/Spider2/blob/main/spider2-lite/resource/documents/ga4_obfuscated_sample_ecommerce.events.md),
[dimensioni e metriche](https://github.com/xlang-ai/Spider2/blob/main/spider2-lite/resource/documents/ga4_dimensions_and_metrics.md)
e [categorie delle pagine](https://github.com/xlang-ai/Spider2/blob/main/spider2-lite/resource/documents/ga4_page_category.md).
Coprono campi annidati, classificazione dei canali e regole di interpretazione;
sono più vicini al requisito semantico. Tuttavia la
[distribuzione Spider è BigQuery](https://github.com/xlang-ai/Spider2/tree/main/spider2-lite/resource/databases/bigquery/ga4):
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.