Come funzionano le visualizzazioni in un DBM?

Question

Dire che ho due tabelle come quelle:

Employers (id, name, .... , deptId).
Depts(id, deptName, ...).

Ma quei dati non verranno modificati così spesso e voglio che una query come questa

SELECT name, deptName FROM Employers, Depts 
    WHERE deptId = Depts.id AND Employers.id="ID"

essere il più veloce possibile.

Alla mia testa ci sono due possibili soluzioni:

• Denormalizza la tabella:

  Nonostante ciò, con questa soluzione perderò alcuni dei grandi vantaggi di avere database "normalizzati", ma qui le prestazioni sono DEVE.

• Crea una vista per denormalizzare i dati.

  Manterrò i dati normalizzati e ( ecco la mia domanda ), l'esecuzione di una query su quella vista sarà più veloce di quella senza quella vista.

O un altro modo di porre la stessa domanda, la vista è "Interpretata" ogni volta che si esegue una query su di esso o come funzionano le visualizzazioni Stuff in un DBA ?.

Answer 1

Generalmente, a meno che tu non "materializzi" una vista, che è un'opzione in alcuni software come MS SQL Server, la vista viene semplicemente tradotta in query rispetto alle tabelle di base e pertanto non è più veloce o più lenta dell'originale (meno il minimo tempo necessario per tradurre la query , che è nulla rispetto all'esecuzione effettiva della query).

Come fai a sapere che hai problemi di prestazioni? Stai profilandolo sotto carico? Hai verificato che il collo di bottiglia delle prestazioni è rappresentato da queste due tabelle? Generalmente, fino a quando non si ottengono dati concreti, non dare per scontato che tu sappia da dove provengono i problemi di prestazioni e non perdere tempo a ottimizzare fino a quando non sai che stai ottimizzando la cosa giusta: l'80% dei problemi di prestazioni proviene da 20 % del codice.

Answer 2

Se Depts.ID è la chiave primaria di quella tabella e indicizzi il campo Employers.DeptID, questa query dovrebbe rimanere molto veloce anche su milioni di record.

La denormalizzazione non ha senso per me in quello scenario.

In generale, le prestazioni di una vista saranno quasi identiche alle prestazioni quando si esegue la query stessa. Il vantaggio di una vista è semplicemente quello di astrarre quella query, quindi non devi pensarci.

Puoi utilizzare una vista materializzata (o "quotazione" come alcuni dicono), ma i tuoi dati saranno recenti solo come l'ultimo aggiornamento.

Answer 3

In un commento a una delle risposte, l'autore della domanda spiega che sta cercando un modo per creare una visione materializzata in MySQL.

MySQL non racchiude il concetto di visualizzazione materializzata in un bel pacchetto per te come altri DBMS, ma ha tutti gli strumenti necessari per crearne uno.

Quello che devi fare è questo:

1. Crea la materializzazione iniziale del risultato della tua query.
2. Crea un trigger su insert nella tabella dei datori di lavoro che inserisce nella tabella materializzata tutte le righe che corrispondono al nuovo datore di lavoro inserito.
3. Crea un trigger all'eliminazione nella tabella dei datori di lavoro che elimina le righe corrispondenti dalla tabella materializzata.
4. Crea un trigger all'aggiornamento nella tabella dei datori di lavoro che aggiorna le righe corrispondenti nella tabella materializzata.
5. Lo stesso vale per la tabella dei dipartimenti.

Questo potrebbe funzionare bene se le tue tabelle sottostanti non vengono aggiornate frequentemente; ma devi essere consapevole del costo aggiuntivo delle operazioni di creazione / aggiornamento / eliminazione una volta fatto questo. Inoltre, ti assicurerai che alcuni DBA che non conoscono i tuoi stratagemmi non migrino il database senza migrare i trigger, quando verrà il momento. Quindi documentalo bene.

Answer 4

Sembra un'ottimizzazione prematura a meno che tu non sappia che si tratta di un problema chiaro e presente.

MySQL non materializza le viste, non sono più veloci delle query rispetto alle tabelle di base. Inoltre, in alcuni casi sono più lenti in quanto vengono ottimizzati meno bene.

Ma visualizza anche " nascondi " cose degli sviluppatori che gestiscono il codice in futuro per far loro immaginare che la query sia meno complessa di quanto non sia in realtà.