Je zou de kolommen 'hard-coded' in de bron kunnen zetten, ik denk dat ik er vanuit mag gaan dat die niet vaak veranderen, en dan is het efficiënter om het er hard-coded in te zetten.
Ontzettend handige dingen trouwens die views! Die moet ik vaker gaan gebruiken, volgens mij heel wat makkelijker dan een complexe query met JOINS aan alle kanten.
Je zou de kolommen 'hard-coded' in de bron kunnen zetten, ik denk dat ik er vanuit mag gaan dat die niet vaak veranderen, en dan is het efficiënter om het er hard-coded in te zetten.
Is geen optie dan komt er in de slectbox te staan tabel.veld ipv van veld
Ow, jammer. Het klonk al een beetje te mooi om waard te zijn, alhoewel je in de programmeerwereld toch hier en daar wel wonderen tegenkomt ;)
Hmm, tijd voor wat testjes? Een case-study over MySQL VIEW, en eventueel een bijpassende tutorial. Als Jan Koehoorn het niet al heeft gedaan, zal ik het zelf maar moeten doen.
-> toegevoegd aan mijn todo-lijst*
* dit ding is puur idealistisch, dus of het er ooit echt van komt...
Mijn voorbeeld van overijverig versimpelen: dataobjecten die automatisch alle kolom-namen en daarbij horende keys en default waarden ophaalden. Weer 1 sql-query per uniek object erbij, terwijl ik deze gegevens alleen gebruik waneer ik iets wil wijzigen of toevoegen in de database (wijzigen -> key nodig, toevoegen -> defaults nodig) en de tabel-structuur verandert zelden. Dus nu overgestapt op een tabel-definitie in de extend van een abstracte klasse. Zelfde effect, maar scheelt wel weer 0.1 seconde laadtijd :)
[quote='Jelmer schreef op 08.10.2006 21:36']Je zou de kolommen 'hard-coded' in de bron kunnen zetten, ik denk dat ik er vanuit mag gaan dat die niet vaak veranderen, en dan is het efficiënter om het er hard-coded in te zetten.
Is geen optie dan komt er in de slectbox te staan tabel.veld ipv van veld
[Of] a'weer een bugje opgelost zie ik :) [/quote]
Je kan ook creatief zijn met aliassen (keys & values van een tabel gebruiken, ook wel bekend als hashtable) of exploden op de . en alleen het achterste deel weergeven.
Ik zie ook al dat de edit-knopjes opgelost zijn, leuk!
[quote='Klaasjan schreef op 08.10.2006 21:49'][quote='Jelmer schreef op 08.10.2006 21:36']Je zou de kolommen 'hard-coded' in de bron kunnen zetten, ik denk dat ik er vanuit mag gaan dat die niet vaak veranderen, en dan is het efficiënter om het er hard-coded in te zetten.
Is geen optie dan komt er in de slectbox te staan tabel.veld ipv van veld
[Of] a'weer een bugje opgelost zie ik :) [/quote]
Je kan ook creatief zijn met aliassen (keys & values van een tabel gebruiken, ook wel bekend als hashtable) of exploden op de . en alleen het achterste deel weergeven.
Ik zie ook al dat de edit-knopjes opgelost zijn, leuk![/quote]
Ben ik met je eens maar ik wil het met SQL doen anders is het nooit meer makkelijk aan te passen.
En van je vorige verhaal snapt een simpele ambtenaar(ikke) helemaal niets
Het kwam erop neer dat ik voor ieder resultaat, iedere regel die ik ophaalde uit de database ook de structuur van de tabel ophaalde. Ik haalde dus gegevens op die nooit veranderen, oftewel: totaal nutteloos en enorm langzaam.
Maar zo moeilijk is maken van wat aliassen toch niet?
$fields = array(
'veld 1' => 'tabel1.naam',
'veld 2' => 'tabel1.pinda',
'veld 3' => 'COUNT(tabel2.id)'
);
het menuutje nu maken met [php]array_keys[/php] als invoer, en bij het ontvangen van de post-data even alle ontvangen veldnamen door $fields[$_POST['field'][$i]] halen.
Ik dacht dat ik een goed idee had. Ik heb ipv een VIEW een tabel gemaakt maar waarom voeft hij nu geen data in?
CREATE TABLE beste
AS SELECT
a.woz AS woz,
b.wijk AS wijk,
a.plaats AS plaats,
a.straat AS straat,
a.nr AS nr,
b.soc AS soortobject,
e.bouwjaar,
a.waarde AS waarde,
b.groep AS groep,
d.datum AS datum,
d.vkc AS vkc,
d.aard AS aard
FROM
stuf20 a,
stuf21 b,
stuf53 c,
stuf52 d,
stuf22 e
WHERE a.woz = b.woz
AND c.woz = b.woz
AND a.woz = RIGHT( e.woz, 11 )
AND c.volgnr = d.volgnr
AND d.datum <>' ';