Hallo,
Ik vraag mij af of het een goede methode is binnen webapplicaties om met CREATE VIEW te werken om vervolgens sneller gegevens te tonen dmv PHP?
Ik gebruik dit nu om tabellen samen te voegen tot 1 tabel.

Zijn hier betere manieren voor, zo ja welke?
Aub even in SQL en databases zetten, dit is geen koffiehoek ;)
Wout schreef op 11.07.2007 13:22
Hallo,
Ik vraag mij af of het een goede methode is binnen webapplicaties om met CREATE VIEW te werken om vervolgens sneller gegevens te tonen dmv PHP?
Ik gebruik dit nu om tabellen samen te voegen tot 1 tabel.

Zijn hier betere manieren voor, zo ja welke?


Mijn idee over views is eigenlijk gezecht ook niet zo heel erg goed ik bedoel van het is alleen maar extra ruimte die dingen ophaald vanuit dezelfde database als de view zelf staat het is eigenlijk alleen echt heel makkelijk en handig als mensen in hun code maar 1 oproep regel willen hebben staan en dat is dan de oproep regen van de view waardoor ze niet zelf de hele vergelijkingen moeten maken in code....

Groetjes..
Het is inderdaad makkelijker een SELECT statement uit te voeren op een VIEW dan op meerdere tabellen.
Een VIEW is eigenlijk een opgeslagen query.

Een VIEW maak je door het volgende statement:

CREATE VIEW my_view AS 
SELECT * FROM tabel


Dit is overigens een vrij onzinnige VIEW

CREATE VIEW my_query AS
SELECT 
	   	woz.*, 
	   	tax.SOORT_OBJECT,
		ond.ONDERDEEL AS NR
FROM 
	 	WAATON ond,
	 	WAATAX tax,
	 	VGWOZ woz
WHERE 
	  	ond.SOORT_OBJECT = '872A'
AND 
		ond.WAARDE < '-9999'
AND
   		woz.IDENT=tax.IDENT_WOZ
AND
   		ond.IDENT_WOZ =tax.IDENT_WOZ
AND
   		tax.PEILDATUM_TYD='01-01-2005'		
AND 
		woz.DATUM_EINDE IS NULL		


Lijkt is vaak een stuk handiger omdat je nu gewoon kunt doen


SELECT * FROM my_query


Je kan trouwens een SELECT statement ook als een soort van VIEW behandelen bijv

SELECT * FROM
SELECT 
	   	woz.*, 
	   	tax.SOORT_OBJECT,
		ond.ONDERDEEL AS NR
FROM 
	 	WAATON ond,
	 	WAATAX tax,
	 	VGWOZ woz
WHERE 
	  	ond.SOORT_OBJECT = '872A'
AND 
		ond.WAARDE < '-9999'
AND
   		woz.IDENT=tax.IDENT_WOZ
AND
   		ond.IDENT_WOZ =tax.IDENT_WOZ
AND
   		tax.PEILDATUM_TYD='01-01-2005'		
AND 
		woz.DATUM_EINDE IS NULL		
ORDER BY
als ook gewoon werken ( niet nuttig overigens)
Ik heb het zelf nu zo:

<?php
include '../../dbconf.php';
$database="debiteur";
mysql_select_db($database,$dblink) or trigger_error(mysql_error()); 

$view = "CREATE OR REPLACE VIEW srvcnr AS
SELECT *
FROM srvcnr_ts
UNION ALL
SELECT *
FROM srvcnr_bs
UNION ALL
SELECT *
FROM srvcnr_bsu";

mysql_query($view);

$sql2 = "SELECT
             *   
         FROM 
             srvcnr
         WHERE 
             debnr LIKE '".$_GET['debnr']."'" or trigger_error (mysql_error());
?>
Dat is iog veel makkelijker dan die qeury die je eerst had. UNION neenmt echter volgens mi j wel veel resources en je hebt het bijna alleen nodig als je datamodel niet juist is
Waarom gebuik je eigenlijk Views als ik vragen mag ?

Naar mijn idee zijn ze niet echt efficient... namelijk..

Groetjes..
Marco schreef op 13.07.2007 11:52
Waarom gebuik je eigenlijk Views als ik vragen mag ?

Naar mijn idee zijn ze niet echt efficient... namelijk..

Groetjes..


Dat was ook de topic-vraag..
Waarom vind je het dan niet efficient en wat zou jij doen??
Mij lijken ze juist handig waneer je veel queries gaat uitvoeren op data die snel zijn geldigheid verliest, met name gegenereerde data dus.

Stel dat je een groots overzicht wilt maken met ieder z'n loon en werkuren van deze week, en ze ook onderling wil vergelijken. Het uitrekenen van het loon is een (voor de situatie even) ingewikkelde functie, en het onderling vergelijken kan niet in 1 query. Mij lijkt het efficiƫnt om dan eerst een view te maken waarin je in 1 keer alle lonen uitrekent, en daarna al die andere queries op die view uit gaat voeren zodat je niet voor al die queries een loon hoeft te berekenen.

Kortom: je slaat de uitvoer van een functie uit zodat je die niet dubbel hoeft op te slaan. Zie het als het opslaan van een waarde van een functie die je vaak nodig hebt, maar waarvan de functie uitvoeren veel tijd kost en binnen de tijd dat je de waarde nodig hebt niet van uitvoer veranderd. Soort bufferen dus.

Dit vermoed ik overigens. Ik heb geen idee hoe views intern werken. Maar je kan ook tabellen van het type MEMORY aanmaken staat mij ergens bij, en daar dan waarden in inserten en achteraf de tabel droppen. Ik denk dat dat vergelijkbaar is.
Een view is inderdaad een opgeslagen sql
de load van een view ligt dus ook aan de load van de sql.

overigens schijnt het dat je in mysql een view kunt UPDATEN (wat natuurlijk onzin is.)

Bij goed genormaliseerde databases zijn views haast onmisbaar omdat je anders in elk script paginalange sqlletjes moet schrijven. Dat hoeft bij een view dus niet
Hier een artikel waarin het sterk wordt afgeraden om VIEWs te gebruiken. Het schijnt slecht te zijn voor de performance en dat wil je niet.

Het betreft overigens SQL Server, wellicht dat er voor MySQL en/of PostgreSQL andere regels gelden. Ga er eens mee testen, dan kun je zelf ontdekken hoe VIEW's zich in jouw database gedragen.

Als beter alternatief wordt de stored procedure aangeraden. Ben ik zelf ook een groot fan van, maar dan vooral omdat het weer eens wat anders is dan PHP...

Reageren