Created on https://www.dvdvideosoft.

com/free-youtube-subtitles-download

hello in this session we will talk about

what is materialized view this is hassan

mir from zero to pro training comm a

materialized view is defined as a

database object that contains the

results of a query if you want to gain

performance advantage then creating a

view is not going to give you that you

might want to create a materialized view

so what is a materialized view in

comparison with a view so if you create

a matrix view then the database

management system will actually store

the resultant data in a table like

structure called materialized view it is

not simply a window on the base table it

is actually a separate object holding

data in itself just like table

the sample command you would use in

Oracle to create a materialized view now

obviously since this is an object

holding data it is not a window anymore

on the base table so now we have a

refresh in the picture a refresh has to

take place periodically that will

reflect the changes in the base table

into this materialized view and you

define the refresh rate in the create

materialized view command that you used

to create the materialized view so the

bottom line is that there is a lag now

in the Refresh in case of a view

whenever you make any changes to the

base table it would be reflected

immediately in the view if you delete a

record from base table it will be

removed from the view immediately if you

update a value in the base table it will

be reflected immediately as updated in

the view but in case of materialized

view there is a lag and the lag is

dependent on the refresh rate you have

selected so in case of a materialized

view you can do the same query that we

did in case of the view now we are doing

this query on the method materialized

view but now there is a difference the

difference is that when you do this

query on the materialized view underline

query is not run by the database

management system the underlying curry

is only run once when the materialized

view was created and it will be run when

it

we'll be refreshed but not every time

when you query the materialized view so

this results into tremendous performance

advantage and indexes on the base table

are obviously not being used when you're

hitting the materialized view and you

can however create indexes on the

materialized view itself because now

like a table storage it's a structure

holding data so if you need a

performance gain further you can

consider creating indexes on relevant

columns within the materialized view so

the purposes for materialized view would

remain almost the same that you saw in

case of a view but I'm using the term

here copy of a table rather than synonym

of a table because a table is holding

data you might want to create a view

holding the same data as in the table

for some reason and that way data in a

table will be copied over to the

materialized view and any changes in the

base table would be reflected

periodically

in the materialized view other than that

you can create a materialized view to

reflect summarization of the detail data

and the base table or to create a sub

set of subsets window on the base table

the window is not a right term here

because now it is holding a separate

copy so if the base table has 20 columns

may feel like you can reflect 10 of

those columns and maybe a filtered data

in terms of rows as well and

materialized view can hold joins of

multiple table this is where the real

performance advantage comes in because

if you create a view which is a join of

multiple tables the performance could be

very slow and you might be forced into

creating a materialized view to fix the

performance issues so here is a quick

comparison between a view and a

materialized view a view basically gives

you up to date data so this is the

biggest advantage of a view but gives

you a slower performance for the reason

I already explained because every time

you call a view the underlying SQL is

executed all the time so if you are

joining multiple tables in a view then

every time the join statement will be

called and it will slow down the

performance in case of materialist view

the data is not so much up to date

because there's a lag and you can

control the refresh rate however the

performance is much much faster keep in

mind that materialized views could be

created on tables which are residing

outside the database in a different

database so in that scenario a

materialized view would be called a

snapshot and materialized view that is

reflecting a data in a table which is

within the same database it will simply

be called the materialized view so

snapshot is a term that is used

specifically to reflect this scenario

where materialized view is created on a

table which is in a different database

the feature of materialized view is

available in all table databases

including oracle sybase IBM db2 and

microsoft SQL Server Oracle added this

feature in race 8i and the terms are

sometimes used differently in db2 it's

called the materialized query table in

Microsoft SQL Server it is called

indexed views MySQL and PostgreSQL they

do not offer materialized view feature

natively however we can create

materialized view ourself by using

triggers and the programming language so

we can create another table and we can

write triggers and we can tell trigger

update this table automatically whenever

the base table is updated so that way we

can end up creating our materialized

views