---

Hey

Jeg sidder igen med nogle bruger muligeder som checkboxe, som brugerne selv
skal kunne redigere(afmeld/tilmeld div. features) og kunne egenligt godt
tænke mig at høre, hvad I andre gør i disse situationer.

I det nuværende eks. er der 6 valgmuligheder, lad os sige at brugeren har
hakket 3 af, hvad er så det smarte rent performance mæssigt, samt
kodemæssigt?

Nemmest er at slette alle entries for brugeren, derefter rende arrayet
igennem for hakkede features og indsætte dem igen. Det giver 7 kald til
databasen(mysql_query() 6 INSERT + 1 DELETE).

Det "pæne" kode er at hente nuværende valgte features, sammenligne dem med
de nye valgte. Derefter:
slette alle nuværende, der ikke er valgt i det nye
indsætte alle nye, som ikke er i det nuværende
og lade alle, der har samme værdi forblive uændret

at hente alle nuværende giver 3 rows og et kald
vælges alle 6, giver det 3 kald til databasen(INSERT) = 4 i alt
vælges ingen, giver det 1 kald til databasen(DELETE) = 2 i alt
vælges 3 nye, giver det 4 kald til databasen(3 INSERT & 1 DELETE)

altså mindre belastning på databasen ved at lave sammenligningen, men mere
kode

Sidst så påtænker jeg at lave en funktion til dette, da jeg ofte bruger
netop denne fremgangsmåde.

Hvad er Jeres erfaringer/fremgangsmåder/mening/tanker ang. dette?

--
Take Care
Kim Emax
http://www.emax.dk
http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop

---

On Fri, 7 Dec 2001 20:47:50 +0100, "Kim Emax - ayianapa.dk"
<newsgroup@sletdette-ayianapa.dk> wrote:

>I det nuværende eks. er der 6 valgmuligheder, lad os sige at brugeren har
>hakket 3 af, hvad er så det smarte rent performance mæssigt, samt
>kodemæssigt?
>
>Nemmest er at slette alle entries for brugeren, derefter rende arrayet
>igennem for hakkede features og indsætte dem igen. Det giver 7 kald til
>databasen(mysql_query() 6 INSERT + 1 DELETE).

>Det "pæne" kode er at hente nuværende valgte features, sammenligne dem med
>de nye valgte. Derefter:
>slette alle nuværende, der ikke er valgt i det nye
>indsætte alle nye, som ikke er i det nuværende
>og lade alle, der har samme værdi forblive uændret
>
>at hente alle nuværende giver 3 rows og et kald
>vælges alle 6, giver det 3 kald til databasen(INSERT) = 4 i alt
>vælges ingen, giver det 1 kald til databasen(DELETE) = 2 i alt
>vælges 3 nye, giver det 4 kald til databasen(3 INSERT & 1 DELETE)

Hvis du bruger mySQL så kan den insætte flere rækker med eet kald:
INSERT INTO tabel (idfelt, felt1) VALUES (1,'hej'), (2, 'med'), (3,
'dig')

Så kan det hele klares med 2 kald til databasen, ligegyldigt om der
vælges en eller alle 6 muligheder.
Og hedder checkboxene noget ala valg[1] så du får en array i hovedet
når formularen postes, så er det nok en ret simpel sag at lave en
funktion som løber denne array igennem og spytter nogle (1,
'hej')-ting ud som kan sættes sammen til din INSERT...

--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403
http://www.gartneriet.dk

Directory Opus - nu også til windows - http://www.gpsoft.com.au

---

"Kim Emax - ayianapa.dk" <newsgroup@sletdette-ayianapa.dk> writes:

> I det nuværende eks. er der 6 valgmuligheder, lad os sige at brugeren har
> hakket 3 af, hvad er så det smarte rent performance mæssigt, samt
> kodemæssigt?

Kodemæssigt er det oftest lettest og mindre fejlfyldt blot at lave et
wrapperlag uden om alle de databasekald man laver. Så du har et klart
defineret interface til at afmelde/tilmelde med nogle relativt simple
funktionskald.

Det er dog ikke altid så hurtigt, og kan koste nogle ekstra kald til
databasen. Men gør det noget? Er din server så meget i knæ at det er
vigtigt om der bliver lavet 4 eller 8 (simple) select-kald
pr. sidevisning? I så fald bør du IMHO overveje at opgradere den

Det er rigtigt at det kan være fristende at optimere kode, men det
giver ofte problemer, som ikke er værd at have. Måske ikke nu, måske
heller ikke i morgen, men så om et år når nogen andre end dig skal
vedligeholde koden og har hamrende svært ved at gennemskue dine
optimeringer.

> Hvad er Jeres erfaringer/fremgangsmåder/mening/tanker ang. dette?

Ovenstående er mine erfaringer. Jeg har prøvet at sidde med noget
gammel kode, som var skrevet i en fart af andre. Det tager *meget*
længere tid at lave selv mindre rettelser, hvis tingene ikke er kodet
på en let forståelig og logisk måde.

Så hellere lave de par ekstra kald til databasen (så længe det
naturligvis ikke er ekstremt!) og opgradere serveren en måned
før. Lønninger løber hurtigt op

--
Jacob - www.bunk.cc
You can never trust a woman; she may be true to you.

---

Davs

Jeg plejer at følge denne opskrift, når der er opdateringer af databasen på
spil:

Når siden sættes op, skriver man både check-boksen
<input type="check" name="bla" value=" ">
og et skjult felt
<input type="hidden" name="bla_original" value=" ">

Når der så bliver trykket på submit, kan man sammenligne værdien af "bla" og
"bla_original" -- hvis de er forskellige opdateres databasen, og ellers
blæser man den et stykke.

Det giver lidt mere trafik, idet man skriver to form-felter i stedet for et,
men til gengæld kan checket foregå uden om databasen, som kun skal lave
noget, når der er ændringer.

/Thomas

---

"Thomas Lindgaard" <thomas@it-snedkeren.dk> skrev

> Når siden sættes op, skriver man både check-boksen
> <input type="check" name="bla" value=" ">
> og et skjult felt
> <input type="hidden" name="bla_original" value=" ">
>
> Når der så bliver trykket på submit, kan man sammenligne værdien af "bla"
og
> "bla_original" -- hvis de er forskellige opdateres databasen, og ellers
> blæser man den et stykke.
>
> Det giver lidt mere trafik, idet man skriver to form-felter i stedet for
et,
> men til gengæld kan checket foregå uden om databasen, som kun skal lave
> noget, når der er ændringer.

neat, det giver dog muligheder for at sende falske værdier afsted men, det
må folk selv om. Det er dem, det går ud over

--
Take Care
Kim Emax
http://www.emax.dk
http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop

---

On Fri, 07 Dec 2001 20:47:50 +0100, Kim Emax - ayianapa.dk wrote:

> Jeg sidder igen med nogle bruger muligeder som checkboxe, som brugerne
> selv skal kunne redigere(afmeld/tilmeld div. features) og kunne egenligt
> godt tænke mig at høre, hvad I andre gør i disse situationer.

For så vidt at valgmulighederne er veldefineret og begrænsede kan det være
en god ide at bruge bit flags -- altså gemme alle indtastningerne i et
enkelt integer felt i databasen.

Herved kræves der 1 UPDATE for at opdatere brugerens valg, og en SELECT
der returnerer 1 række for at hente indtastningerne.

/A

---

"Anders Johannsen" <anders@ignition.dk> skrev

> For så vidt at valgmulighederne er veldefineret og begrænsede kan det være
> en god ide at bruge bit flags -- altså gemme alle indtastningerne i et
> enkelt integer felt i databasen.
>
> Herved kræves der 1 UPDATE for at opdatere brugerens valg, og en SELECT
> der returnerer 1 række for at hente indtastningerne.

du tænker at værdien er:

user_id settings

12 1,4,5,6

?

det vil være en god måde at gøre det på

--
Take Care
Kim Emax
http://www.emax.dk
http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop

---

On Sat, 08 Dec 2001 00:37:07 +0100, Kim Emax - ayianapa.dk wrote:

> du tænker at værdien er:
>
> user_id settings
>
> 12 1,4,5,6
>
> ?
>
> det vil være en god måde at gøre det på

Ja -- og nej.

Hvis vi som ovenfor antager at brugeren har valgt mulighed nummer 1,4,5,6
ville resultatet være 1<<1|1<<4|1<<5|1<<6 , altså

   user_id settings

   12 114

For at finde alle folk, som har valgt mulighed 4 kan man

   SELECT * FROM table WHERE setting & 1<<4

Mulighed 4 og 6

   SELECT * FROM table WHERE setting & (1<<4|1<<6)11

Alle muligheder undtagen 4

   SELECT * FROM table WHERE setting & ~(1<<4)


/A

---

"Anders Johannsen" <anders@ignition.dk> writes:

> For så vidt at valgmulighederne er veldefineret og begrænsede kan det være
> en god ide at bruge bit flags -- altså gemme alle indtastningerne i et
> enkelt integer felt i databasen.

Men så skal valgmulighederne altså også være enormt veldefinerede for
at det er noget man senere kan overlade til andre programmører uden
videre besvær.

Det kræver også at man lige bruger 5 minutter på at lave noget
dokumentation der fortæller hvad disse enormt veldefinerede
valgmuligheder er, igen så andre kan sætte sig ind i det uden at rive
håret af sig selv.

> Herved kræves der 1 UPDATE for at opdatere brugerens valg, og en SELECT
> der returnerer 1 række for at hente indtastningerne.

Nu er det måske bare mig. Men jeg forstår ikke denne mani med at
minimere antallet af databasekald. Sådan nogle kan være mere eller
mindre komplekse, det har i høj grad også en del at sige.

Men er det ikke vigtigere at ens kode virker - også når der er flere
forskellige programmører der har haft fat i det - end at man sparer en
lille smule load på en databaseserver? Jeg kan se relevansen, hvis man
i forvejen har en KÆMPE databaseserver, som ikke kan følge med fordi
der er for meget load på den, men den slags sites er der altså ikke
enormt mange af her i lille Danmark.

Forstå mit ret, det er OK at optimere hvor det er åbenlyst hvad der
sker, men optimeringer bare for optimeringens skyld giver jeg altså
ikke så meget for.

--
Jacob - www.bunk.cc
I fear explanations explanatory of things explained.

---

On Sat, 08 Dec 2001 12:34:57 +0100, Jacob Bunk Nielsen wrote:

>> For så vidt at valgmulighederne er veldefineret og begrænsede kan det
>> være en god ide at bruge bit flags -- altså gemme alle indtastningerne
>> i et enkelt integer felt i databasen.
>
> Men så skal valgmulighederne altså også være enormt veldefinerede for at
> det er noget man senere kan overlade til andre programmører uden videre
> besvær.

Som nævnt, ja.

> Det kræver også at man lige bruger 5 minutter på at lave noget
> dokumentation der fortæller hvad disse enormt veldefinerede
> valgmuligheder er, igen så andre kan sætte sig ind i det uden at rive
> håret af sig selv.

Et eksempel på en fornuftig brug af bit flags er ved rettighedsstyring.

> Men er det ikke vigtigere at ens kode virker - også når der er flere
> forskellige programmører der har haft fat i det - end at man sparer en
> lille smule load på en databaseserver? Jeg kan se relevansen, hvis man i
> forvejen har en KÆMPE databaseserver, som ikke kan følge med fordi der
> er for meget load på den, men den slags sites er der altså ikke enormt
> mange af her i lille Danmark.

Jeg kan ikke forstå hvorfor du synes at brugen af bit flags til at gemme
visse informationer i "veldefinerede og begrænsede" tilfælde, evt.
bundlede med konstanter i koden, står i modsætningsforhold til at koden
virker.

Som jeg fremhævede, er det beskrevne ikke en almen fremgangsmåde, men
udelukkende brugbart i visse tilfælde.

/A

---

"Anders Johannsen" <anders@ignition.dk> writes:

> Jeg kan ikke forstå hvorfor du synes at brugen af bit flags til at gemme
> visse informationer i "veldefinerede og begrænsede" tilfælde, evt.
> bundlede med konstanter i koden, står i modsætningsforhold til at koden
> virker.

Det gør det heller ikke umiddelbart. Men det gør det måske når der er
3 forskellige programmører der har haft fat i koden og en af dem ikke
100% forstod idéen i den måde det var lavet på.

Det jeg prøver at komme frem til er at det ofte er en god ting at
holde et relativt højt abstraktionsniveau, og så lade performance
komme i anden række. Løber man så ind i et performance-problem, så kan
man give sig til at analysere hvor det bliver for tungt og så måske
nøjes med at skrive den kodestump lidt anderledes, eller måske bare
opgradere den 486'er man har stående som server

> Som jeg fremhævede, er det beskrevne ikke en almen fremgangsmåde, men
> udelukkende brugbart i visse tilfælde.

OK, så tror jeg vi er nogenlunde enige.

--
Jacob - www.bunk.cc
If life gives you lemons, make lemonade.

---

> For så vidt at valgmulighederne er veldefineret og begrænsede kan det være
> en god ide at bruge bit flags -- altså gemme alle indtastningerne i et
> enkelt integer felt i databasen.

Enig i at det er ekstremt plads-effektivt, men er det nu også "smart"? Det
er da temmeligt "u-database-agtigt" ;)

Primært usmart imho af de allerede nævnte grunde: Misforstået optimering
giver uforståelig og u-vedligeholdelig kode.

Det virker lidt vildt at bruge en stor, tung, dyr database med B-træer,
sikkerhed, rollback osv. blot for at gemme bitmønstre...


--
Mvh. Mogens
www.momech.dk

---

On Sat, 08 Dec 2001 16:27:38 +0100, Mogens Meier Christensen wrote:

>> For så vidt at valgmulighederne er veldefineret og begrænsede kan det
>> være en god ide at bruge bit flags -- altså gemme alle indtastningerne
>> i et enkelt integer felt i databasen.
>
> Enig i at det er ekstremt plads-effektivt, men er det nu også "smart"?
> Det er da temmeligt "u-database-agtigt" ;)

Det er nok værd at bemærke, at spørgeren eftersøgte en måde at minimere
antallet af kald til databasen, og at svaret ikke udgav sig for at være
en generel fremgangsmåde.

> Primært usmart imho af de allerede nævnte grunde: Misforstået optimering
> giver uforståelig og u-vedligeholdelig kode.

Jeg er ikke sikker på hvorfor det er "misforstået optimering" under de
nævnte forudsætninger, men konklusionen er rigtig.

/A

---

"Anders Johannsen" <anders@ignition.dk> writes:

> Det er nok værd at bemærke, at spørgeren eftersøgte en måde at minimere
> antallet af kald til databasen, og at svaret ikke udgav sig for at være
> en generel fremgangsmåde.

Det var ikke mit indtryk af det oprindelige indlæg. Jeg forstod det
snarere som et "Hvordan gør I andre ... ?"-indlæg, hvor spørgen
fremlægger de metoder med fordele og ulemper han lige kan komme i
tanke om.

--
Jacob - www.bunk.cc
Lost interest? It's so bad I've lost apathy.

---

"Jacob Bunk Nielsen" <spam@bunk.cc> skrev

> Det var ikke mit indtryk af det oprindelige indlæg. Jeg forstod det
> snarere som et "Hvordan gør I andre ... ?"-indlæg, hvor spørgen
> fremlægger de metoder med fordele og ulemper han lige kan komme i
> tanke om.

Korrekt, læs mit follow-up til indlægget.

--
Take Care
Kim Emax
http://www.emax.dk
http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop

---

Hey der

Jeg må sige at det var interessant at læse Jer andres fremgangsmåde og
tanker i forbindelse med nævnte kodestump. Der er meget at tage hensyn til.
At koden skal være overskuelig er bestemt en af dem, og det er sikkert at
delete/insert er den nemmeste måde at fikse det på. Samler man så alle
inserts i en query og har en delete først, derefter fyrer den gennem
mysq_query() er man nede på et kald til databasen. Eneste ulempe er, hvis
man evt. vil bruge de oprindelige info(f.eks. en created) til noget
statistik eller whatever, jeg kan ikke lige komme på noget, såeee...

En anden ting, jeg ynder at gøre er at have alle valgmuligheder(checkboxe) i
en tabel og hente derfra. Det giver lidt overdrevet performance misbrug,
sammenlignet med at have det statisk i koden. Bliver siten for belastet, har
mine tanker altid været at lade cron lave en text fil, hvor valgmulighederne
er listet, og derefter lade valgmulighederne ligge i et array. Igen, hvad er
mest gennemskueligt for koden og den næste programmør?

Alt i alt, syns jeg det var en spændende tråd, jeg håber, der kommer flere
af den slags.

--
Take Care
Kim Emax
http://www.emax.dk
http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop