Materialized Views

Op mijn werk heb ik de beschikking over enkele redelijk grote databases waartegen ik soms grote queries aan moet houden. Ondertussen heb ik geleerd dat je deze handig in een view stoppen kan. De performance daalt hierdoor echter drastisch.
Een oplossing voor dit probleem is een zogenaamde materialized view.
In deze tutorial wil ik jullie een kleine uitleg geven van het principe hierachter, het maken van,het nut van, en de gevaren van een materialized view. Op de laatste pagina vinden jullie nog enkele handige links.

Een materialized view is feitelijk niks anders dan een moment opname van de data uit een view op een bepaald moment.

Bijvoorbeeld.
mannen
1 jan
2 klaas
3 piet
vrouwen
1 evelien
2 claar
3 hilda
koppeltabel
1,3
2,1
3,2
View Stellen zou je bijvoorbeeld zo kunnen maken

CREATE VIEW STELLEN AS
SELECT
Mannnen.naam,
Vrouwen.naam
FROM
        Mannen,
	Vrouwen,
	Koppeltabel
WHERE
	Koppeltabel.man_id=mannen.id
AND
	Koppeltabel.vrouw_id = vrouwen.id

Op het moment dat je deze view aanspreekt wordt dynamisch alle gegevens weer bij elkaar geharkt. Als je deze view echter materialized zou maken, dan blijft de data statisch vanaf het moment dat de view gecompiled is.

CREATE MATERIALIZED VIEW STELLEN AS
 
SELECT
Mannnen.naam,
Vrouwen.naam
FROM
        Mannen,
	Vrouwen,
	Koppeltabel
WHERE
	Koppeltabel.man_id=mannen.id
AND
	Koppeltabel.vrouw_id = vrouwen.id

Maakt dezelfde view alleen dan materialized 

Op de vorige pagina heb je al gezien hoe je een materialized view maakt. Oracle heeft echter ook nog de wereld aan opties die je mee kunt geven. Ik snap dat de meeste van jullie mysql gebruiken toch wil ik de kracht van een echte rdbms hiermee aantonen. (Ook met Postgressql kan je materialized views gebruiken. De hiervoor benodigde functies zitten bij mijn weten niet standaard in de DB maar je kan ze er wel zelf in maken, zie link op de laatste pagina)

Opties;

Refresh -> er zijn in Oracle meerder mogelijkheden een materialized view (statische data) te refreshen.

REFRESH FAST
START WITH SYSDATE
NEXT SYSDATE + 2

Iedere twee dagen wordt de view weer opgebouwd zonder dat je daar zelf iets voor hoeft te doen

On Prebuilt Tables -> deze optie zorgt ervoor dat de materialized view een tabel vult die van tevoren is gemaakt. DE tabel moet dezelfde naam en hebben en in hetzelfde schema zitten als de view.

zo zijn er nog legio opties voor een overzicht hiervan verwijs ik je naar de linken

Het allergrootste voordeel van een materialized view tov een gewone view is de snelheid. Dit heeft er mee te maken dat de materialized view, zeker op basis van een pre-built table, zich feitelijk gedraagt als een tabel. Dus met bijvoorbeeld indexes.

Een ander groot voordeel is het handig en snel data uit een een andere database halen. De materialized view wordt met name gebruikt in Datawarehouses waar data uit vele verschillende bronnen tegen elkaar aangehouden wordt voor bijvoorbeeld het verkrijgen van statische of management informatie.
Door nu elke nacht automatisch alle materialized views te refreshen heb je elke morgen de beschikking over actuele en snelle data.

De gevaren van.
Feitelijk schuilt er maar een groot gevaar en dat is de actualiteit van de data. Deze loopt in een materialized view altijd achter.


Hopelijk is jullie duidelijk geworden wat een materialized view is en hebben jullie hiermee de oplossing voor performance problemen gekregen.

Hieronder nog enkele linken:

http://web.archive.org/web/20070513063121/http://jonathangardner.net/PostgreSQL/materialized_views/matviews.html

http://www.dba-oracle.com/art_9i_mv.htm

http://en.wikipedia.org/wiki/View_(database)

http://jonathangardner.net/tech/w/PostgreSQL/Materialized_Views















.