[MySQL] anomalie su vista

[biamat]

Ciao,
ho un database composto da 4 tabelle con gli stessi identici campi. Queste tabelle sono state riempite ognuna con N righe uguali.
Dopo di che ho creato una vista con questa sintassi:
CREATE VIEW vista AS
SELECT * FROM tabella_1
UNION
SELECT * FROM tabella_2
UNION
SELECT * FROM tabella_3
UNION
SELECT * FROM tabella_4

A questo punto facendo un COUNT sulla vista quello che mi aspetterei di avere come risultato è 4 volte N invece ottengo N.
Ossia è come se la vista escludesse quei valori che sono identici tra le 4 tabelle aggiungendo la clausola DISTINCT.
Dove sbaglio? Qual'è il problema?
Spero di essere stato chiaro.

[webus]

Non sbagli, UNION infatti rimuove i duplicati, come fosse UNION DISTINCT.
Usa UNION ALL per mantenere anche i duplicati.

[biamat]

Ora funziona tutto correttamente!
Grazie.
Se posso pongo un'altra domanda.
Le viste che creo solitamente includono un numero di sottotabelle variabili da 4 a 6 e le uniche operazione che vengono fatte per la loro creazione sono un subset di dati comuni a queste 4/6 tabelle.
Ho deciso di ricorrere alle viste perchè su queste tabelle andranno fatto molte operazioni di ricerca e conteggio dei risultati su un numero limitato di campi di queste tabelle e contenendo una grand mole di informazioni ognuna mi è sembrata la via migliore sia per alleggerire il carico di lavoro sia per diminuire semplicemente il numero di query eseguite.
Ora però sorge un'altra questione: eseguendo una query di ricerca parametrizzata su una vista al primo lancio di queste il tempo di esecuizione è davvero elevato mentre alle esecuzioni sucessive le prestazioni diventano ottime. Il problema è che questo problema si presenta se rieseguo la stessa query di ricerca usando come filtro lo stesso campo ma con un parametro di ricerca differente.
Mi iniziano a sorgere dei dubbi sulla corretta progettazione del database.

[webus]

Originariamente inviato da biamat
Mi iniziano a sorgere dei dubbi sulla corretta progettazione del database.

uhm, mi pare che ti sia anche già risposto.

[biamat]

Provo ad esporti quelle che sono state le scelte che mi hanno portato ad optare per questa soluzione.
Il sistema è una sorta di community suddivisa in categorie e sottocategorie. Ogni sottocategoria conterrà degli annunci, mentre la categoria sarà solo un contenitore di sottocategorie.
Ogni annuncio sarà composto massimo da N campi e ogni categoria sarà composta da un subset di questi N campi: quindi avranno tutte dei campi comuni.
L'idea iniziale era quella di creare un'unica tabella per contenere gli annunci aggiungendo un campo per distinguere la categoria cui apparteneva l'annuncio.
Questa soluzione a mio avviso aveva due svantaggi:
1 - Nel caso di una categoria che non utilizzasse tutti i campi molti sarebbero sempre rimasti vuoti con uno spreco di spazio;
2 - Nell'ottica di popolamento di massa delle community quest'unica tabella degli annunci avrebbe raggiunto dimensioni considerevoli con probabili estremi rallentamenti nelle operazioni di ricerca.
Alla fine ho optato per la realizzazione di una tabella per ogni sottocategoria.
Da notare che le sottocategorie di una stessa categoria sono tutte composte dagli stessi campi: avrei quindi potuto optare per la creazione di un'unica tabella per ogni categoria ma temevo il possibile problema numero 2, ossia tabella enorme e lenta.
Questa soluzione si rivela performante per ricerche all'interno della specifica sottocategoria ma richiedeva un numero enorme di query con UNION per le ricerche all'interno di una sottocategoria: da qui la scelta di optare per l'utilizzo delle viste che si semplificano il numero di query e la loro sintassi ma che hanno quel problema di lentezza alla prima esecuzione.
Sicuramente questo database non è "normalizzato" ma mi sembrava la soluzione più performante: qualche idea?

[webus]

non ci ho capito molto di come è strutturato, nè del perché, ma certamente una vista con una serie di

UNION ALL SELECT *

pùò essere solo tutt'altro che performante.

Credo proprio sia il caso che tu ne riveda la struttura, normalizzata sarebbe meglio.

[biamat]

Riprovo a spiegarti velocemente com'è strutturato il database è perchè, magari potresti essermi di aiuto.
Quello che devo gestire sarà un portale di annunci, divisi per categorie.
Ogni annunci avrà gli stessi campi e l'unica cosa che lo contraddistinguerà da un'altro annuncio sarà la categoria di appartenenza.
Per cui la logica, e la normalizzazione, mi avrebbero dovuto spingere ad utilizzare un'unica tabella per raccogliere tutti gli annunci composta dai campi dell'annuncio e da uno per identificarne la categoria.
Mi sono però posto il problema di un domani in cui il numero di annunci inseriti potrebbe essere davvero elevato e mi sono detto: non sarà lentissima la tabella piena di annunci nelle operazioni di ricerca?
Allora mi sono deciso a creare una tabella per ogni categoria di annunci tutte ovviamente composte dagli stessi campi.
In alcune situazioni però devo fare delle ricerche che coinvolgono più di una categoria contemporaneamente e quindi le strate erano 2: o fare una query per ogni categoria e poi elaborare i dati oppure creare dei sottogruppi di categorie tramite le viste ed interrogare queste viste.
Solo che questa soluzione ha quei problemi di cui ti avevo parlato.
Sono stato un po' più chiaro?

[franz79]

Sei stato più chiaro, ma il problema di fondo resta: se la vista che tu vai a creare è il risultato di UNION ALL SELECT massive, è perfettamente ovvio che le performance saranno assai basse.

E poi: quanto realisticamente pensi che il tuo DB possa crescere? Tieni conto che qualche centinaio di migliaia di righe NON rappresentano un db di grandi dimensioni

[biamat]

Non mi do limiti, potrebbero anche essere decine di milioni di righe.
Continuo a pensarci un po' su.