/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
joins eller løkker
Fra : Leif Neland


Dato : 02-10-09 10:19

Et lidt teoretisk spørgsmål...

En en-til-mange-til-mange relation:
En kunde har mange ordrer, og hver ordre har mange ordrelinier.

Forudsætning: Der bruges ikke stored procedures i databasen;
"mekanikken" ligger i applikationen, f.ex. en webside i php eller asp.

Når man skal vise ordren, laver man så tre request til databasen:
(Pseudokode)

$kundedata=sqlresult("select * from ordrer where id=?",$ordreid)
$kundeid = $kundedata["kundeid"]

$ordredata=sqlresultat("select * from kunder where id=?,$kundeid)
udskriv_ordrehoved($kundedata,$ordredata)
$ordrelinier=sqlresultat(
"select * from ordrelinier where ordreid=?",$ordreid)
foreach($ordrelinier as $ordrelinie) {
udskriv($ordrelinie)
}

Eller lader man databasen trække det hele på en gang?
$ordrelinier=sqlresultat("select * from kunder,ordrer,ordrelinier
where ordrer.id=?
and ordrer.kundeid=kunder.id
and ordrer.id=ordrelinier.ordreid",$ordrelinie)

udskriv_ordrehoved($ordrelinier[0])
foreach($ordrelinier as $ordrelinie) {
udskriv($ordrelinie)
}

Den ene måde laver flere forespøtgsler til database, den anden kun 1,
men til gengæld indeholder hver ordrelinie også kundeoplysningerne.

Det kommer nok an på, hvor effektiv databasen er i forhold til
programmeringssproget, og hvor langt (og "bredt") mellem database og
applikation, så det er nok ligegyldigt i de fleste situationer.

Men hvad lærer ungdommen nu om stunder?

Leif



 
 
Stig Johansen (02-10-2009)
Kommentar
Fra : Stig Johansen


Dato : 02-10-09 10:55

Leif Neland wrote:

> Den ene måde laver flere forespøtgsler til database, den anden kun 1,
> men til gengæld indeholder hver ordrelinie også kundeoplysningerne.

Det handler ligeså meget om trafik fra databasen til applikationslaget.
I nogle tilfælde er det en god ide at optimere trafikken, og i andre
tilfælde er det en god ide at optimere mod databasen.

Det kommer an på hvor flaskehalsen er i dit setup, så man kan ikke lave et
endegyldigt svar (aka 'one size fits all').

> Det kommer nok an på, hvor effektiv databasen er i forhold til
> programmeringssproget, og hvor langt (og "bredt") mellem database og
> applikation, så det er nok ligegyldigt i de fleste situationer.

Jeg tror du blander 'sprog' og databaseklienter sammen her.

> Men hvad lærer ungdommen nu om stunder?

Aner det ikke..

--
Med venlig hilsen
Stig Johansen

Henrik Stidsen (02-10-2009)
Kommentar
Fra : Henrik Stidsen


Dato : 02-10-09 15:04

Leif Neland <leif@neland.dk> wrote in
news:4ac5c5a7$0$36571$edfadb0f@dtext01.news.tele.dk:

> En en-til-mange-til-mange relation:
> En kunde har mange ordrer, og hver ordre har mange ordrelinier.

> Forudsætning: Der bruges ikke stored procedures i databasen;
> "mekanikken" ligger i applikationen, f.ex. en webside i php eller asp.

> Når man skal vise ordren, laver man så tre request til databasen:
[snip]
> Eller lader man databasen trække det hele på en gang?

Jeg ville vælge at lave 1 kald der henter kundens stamdata og et der henter
ordreinformationen. Hvis ordren er bygget af en ordre og en række
ordrelinier vil jeg lave det i 2 kald. Der er ingen grund til at hente
kundens stamdata og ordrehovedet 25 gange hvis der er 25 ordrelinier i
ordren. Ofte vil også skulle behandle dataene hver for sig i sin GUI
(opstille dem i forskellige områder).

--
Henrik Stidsen - http://henrikstidsen.dk/
http://fuglemarkedet.dk/ - Danmarks online fuglemarked!

Arne Vajhøj (03-10-2009)
Kommentar
Fra : Arne Vajhøj


Dato : 03-10-09 00:35

Leif Neland wrote:
> Et lidt teoretisk spørgsmål...
>
> En en-til-mange-til-mange relation:
> En kunde har mange ordrer, og hver ordre har mange ordrelinier.
>
> Forudsætning: Der bruges ikke stored procedures i databasen;
> "mekanikken" ligger i applikationen, f.ex. en webside i php eller asp.
>
> Når man skal vise ordren, laver man så tre request til databasen:
> (Pseudokode)
>
> $kundedata=sqlresult("select * from ordrer where id=?",$ordreid)
> $kundeid = $kundedata["kundeid"]
>
> $ordredata=sqlresultat("select * from kunder where id=?,$kundeid)
> udskriv_ordrehoved($kundedata,$ordredata)
> $ordrelinier=sqlresultat(
> "select * from ordrelinier where ordreid=?",$ordreid)
> foreach($ordrelinier as $ordrelinie) {
> udskriv($ordrelinie)
> }
>
> Eller lader man databasen trække det hele på en gang?
> $ordrelinier=sqlresultat("select * from kunder,ordrer,ordrelinier
> where ordrer.id=?
> and ordrer.kundeid=kunder.id
> and ordrer.id=ordrelinier.ordreid",$ordrelinie)
>
> udskriv_ordrehoved($ordrelinier[0])
> foreach($ordrelinier as $ordrelinie) {
> udskriv($ordrelinie)
> }
>
> Den ene måde laver flere forespøtgsler til database, den anden kun 1,
> men til gengæld indeholder hver ordrelinie også kundeoplysningerne.
>
> Det kommer nok an på, hvor effektiv databasen er i forhold til
> programmeringssproget, og hvor langt (og "bredt") mellem database og
> applikation, så det er nok ligegyldigt i de fleste situationer.
>
> Men hvad lærer ungdommen nu om stunder?

Jeg aner ikke hvad ungdommen lærer.

Generelt er mange alt for hysteriske med at minimere antal
SQL kald. Det er ikke hurtigt at lave SQL kald inden i
en løkke, men i tilfælde som dette om det er 1,2 eller 3
kald er kun et af mange forhold som påvirker performance.

Færre kald vil normalt mindske wall time betydelige, men
det er mere usikkert om belastningen af database serveren
vil blive mindre eller større, fordi færre kald betyder
mere kompleks SQL.

Nogen konstruerer nogle rædsler af SQL sætninger for
at spare et enkelt kald.

I det konkrete tilfælde tror jeg dog at jeg ville gå
efter et enkelt kald. Det er en helt basal join, som jeg
vil forvente at databasen vil kunne udføre meget effektivt.

Men hvis du vil vide det med sikkerhed bliver du nødt til
at teste med din database og dine data.

Arne

Henrik Stidsen (03-10-2009)
Kommentar
Fra : Henrik Stidsen


Dato : 03-10-09 13:56

Arne Vajhøj <arne@vajhoej.dk> wrote in
news:4ac68e27$0$292$14726298@news.sunsite.dk:

> I det konkrete tilfælde tror jeg dog at jeg ville gå
> efter et enkelt kald. Det er en helt basal join, som jeg
> vil forvente at databasen vil kunne udføre meget effektivt.

Databasen kan nok gøre det mindst lige så effektivt, hvis ikke mere, i et
join som i 3 kald - men hvis dataene skal fragtes over netværk mellem
databaseserveren og applikationen så vil der jo blive en betragelig mængde
ekstra data hvis man laver det som en join.

Ofte vil det ikke betyde noget fordi netværkskapaciteten på de netværk der
er tale om er så høj som den er nu til dags - men sidder man med et kæmpe
system med rigtig mange kunder og rigtig mange ordrer kan det jo faktisk
betyde en målbar ekstra trafik.

Som med så mange andre ting skal man nok vurdere de forskellige fordele og
ulemper hver gang man skal vælge, man kan ikke komme med en løsning der er
en ultimativ sandhed.

--
Henrik Stidsen - http://henrikstidsen.dk/
http://fuglemarkedet.dk/ - Danmarks online fuglemarked!

Arne Vajhøj (04-10-2009)
Kommentar
Fra : Arne Vajhøj


Dato : 04-10-09 01:02

Henrik Stidsen wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote in
> news:4ac68e27$0$292$14726298@news.sunsite.dk:
>> I det konkrete tilfælde tror jeg dog at jeg ville gå
>> efter et enkelt kald. Det er en helt basal join, som jeg
>> vil forvente at databasen vil kunne udføre meget effektivt.
>
> Databasen kan nok gøre det mindst lige så effektivt, hvis ikke mere, i et
> join som i 3 kald - men hvis dataene skal fragtes over netværk mellem
> databaseserveren og applikationen så vil der jo blive en betragelig mængde
> ekstra data hvis man laver det som en join.

Næh.

Der bliver ikke flere rækker med den her join.

Der bliver nogle kolonner ekstra, men der spares jo også
2 gange request og 2 gange response overhead.

Medmindre de har usædvaneligt mange ordrelinier per ordre,
så vil jeg forvente mindre netværkstraffik.

> Ofte vil det ikke betyde noget fordi netværkskapaciteten på de netværk der
> er tale om er så høj som den er nu til dags - men sidder man med et kæmpe
> system med rigtig mange kunder og rigtig mange ordrer kan det jo faktisk
> betyde en målbar ekstra trafik.

Hvis man returnerer markant mere data.

Arne

Henrik Stidsen (04-10-2009)
Kommentar
Fra : Henrik Stidsen


Dato : 04-10-09 01:06

Arne Vajhøj <arne@vajhoej.dk> wrote in
news:4ac7e5ff$0$284$14726298@news.sunsite.dk:

> Medmindre de har usædvaneligt mange ordrelinier per ordre,
> så vil jeg forvente mindre netværkstraffik.

Hvis alt kundedata og ordrehovedet skal med for hver ordrelinie bliver der
da vist hurtigt en forøgelse af datamængden på over 100%. Hvor meget fylder
et request?

--
Henrik Stidsen - http://henrikstidsen.dk/
http://fuglemarkedet.dk/ - Danmarks online fuglemarked!

Arne Vajhøj (04-10-2009)
Kommentar
Fra : Arne Vajhøj


Dato : 04-10-09 02:53

Henrik Stidsen wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote in
> news:4ac7e5ff$0$284$14726298@news.sunsite.dk:
>> Medmindre de har usædvaneligt mange ordrelinier per ordre,
>> så vil jeg forvente mindre netværkstraffik.
>
> Hvis alt kundedata og ordrehovedet skal med for hver ordrelinie bliver der
> da vist hurtigt en forøgelse af datamængden på over 100%.

Ikke hvis de kun tager de kune data som skal bruges på ordren.

> Hvor meget fylder
> et request?

Det afhænger jo åbenlyst af databasen.

Men request vil ihvertfald indeholder SQL'en mens respons vil
ihvertfald indeholde meta data med kolonne navne og kolonne
data typer.

Arne


Henrik Stidsen (04-10-2009)
Kommentar
Fra : Henrik Stidsen


Dato : 04-10-09 13:28

Arne Vajhøj <arne@vajhoej.dk> wrote in
news:4ac80008$0$287$14726298@news.sunsite.dk:

>> Hvis alt kundedata og ordrehovedet skal med for hver ordrelinie
>> bliver der da vist hurtigt en forøgelse af datamængden på over 100%.

> Ikke hvis de kun tager de kune data som skal bruges på ordren.

Okay, så vi skal bruge:
Kundedata:
navn, adresse, cvr nummer og firmanavn (hvis det er virksomhed),
faktureringsadresse, kundenummer, evt. telefonnummer
Ordrehoved:
fakturanummer, ordrenummer, dato, vores ref, deres ref,
betalingsbetingelser, betalingsdato

Alt det skal vi have med for hver ordrelinie som indeholder:
Antal, varenummer, varetekst, pris.

Allerede ved 1 ordrelinier ser jeg mere data for kundens stamdata og
ordrehovedet end for ordrelinien - og jeg er ikke sikker på om jeg har det
hele med.

> Men request vil ihvertfald indeholder SQL'en mens respons vil
> ihvertfald indeholde meta data med kolonne navne og kolonne
> data typer.

Det meta data skal jo overføres uanset om man bruger 1 eller 3 requests til
det, kolonnemængden er stort set ens om man bruger 1 eller 3.

--
Henrik Stidsen - http://henrikstidsen.dk/
http://fuglemarkedet.dk/ - Danmarks online fuglemarked!

Stig Johansen (04-10-2009)
Kommentar
Fra : Stig Johansen


Dato : 04-10-09 05:02

Henrik Stidsen wrote:

> Hvis alt kundedata og ordrehovedet skal med for hver ordrelinie bliver der
> da vist hurtigt en forøgelse af datamængden på over 100%.

I og med der er tale om at vise en ordre, vil jeg tror, at allerede ved 2
ordrelinier er man langt over de 100%, dat 'stamdata' på ordrer/kunder
langt vil overstige informationerne på en ordrelinie.

Jeg ved ikke hvorfor i kun snakker om 1 eller 3 forespørgsler, for i det her
tilfælde ville jeg bruge 2.

En SQL til 'stamdata', altså ordrehoved og kundeoplysninger.
Og så en til ordrelinier.

--
Med venlig hilsen
Stig Johansen

Henrik Stidsen (04-10-2009)
Kommentar
Fra : Henrik Stidsen


Dato : 04-10-09 13:23

Stig Johansen <wopr.dk@gmaill.com> wrote in
news:4ac81e81$0$279$14726298@news.sunsite.dk:

>> Hvis alt kundedata og ordrehovedet skal med for hver ordrelinie
>> bliver der da vist hurtigt en forøgelse af datamængden på over 100%.

> I og med der er tale om at vise en ordre, vil jeg tror, at allerede
> ved 2 ordrelinier er man langt over de 100%, dat 'stamdata' på
> ordrer/kunder langt vil overstige informationerne på en ordrelinie.

Enig.

> Jeg ved ikke hvorfor i kun snakker om 1 eller 3 forespørgsler, for i
> det her tilfælde ville jeg bruge 2.
> En SQL til 'stamdata', altså ordrehoved og kundeoplysninger.
> Og så en til ordrelinier.

3 kommer af at jeg forstod det som at der var flere ordre på kunden og at
de alle skulle vises, altså at der var flere ordrehoveder. Helt enig i at
der kun bør være 2 selects hvis der kun er 1 ordre.

--
Henrik Stidsen - http://henrikstidsen.dk/
http://fuglemarkedet.dk/ - Danmarks online fuglemarked!

Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408925
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste