---

Hvordan får jeg php til at skrive kun lidt af den tekst, jeg har
inde i min mysql database?

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

chr wrote:
> Hvordan får jeg php til at skrive kun lidt af den tekst, jeg har
> inde i min mysql database?
>

Tag et kig på:
http://dev.mysql.com/doc/mysql/en/string-functions.html

Tag et kig på SUBSTRING()

mvh
johan

---

"Johan Holst Nielsen" <spam@phpgeek.dk> skrev i en meddelelse
news:4289e61b$0$79454$14726298@news.sunsite.dk...
> chr wrote:
>> Hvordan får jeg php til at skrive kun lidt af den tekst, jeg har
>> inde i min mysql database?
>>
>
> Tag et kig på:
> http://dev.mysql.com/doc/mysql/en/string-functions.html
>
> Tag et kig på SUBSTRING()

Eller PHP's egen substr() funktion:

http://dk2.php.net/manual/en/function.substr.php

Mvh

Carsten

---

Carsten Pedersen wrote:
> "Johan Holst Nielsen" <spam@phpgeek.dk> skrev i en meddelelse
> news:4289e61b$0$79454$14726298@news.sunsite.dk...
>
>>chr wrote:
>>
>>>Hvordan får jeg php til at skrive kun lidt af den tekst, jeg har
>>>inde i min mysql database?
>>>
>>
>>Tag et kig på:
>>http://dev.mysql.com/doc/mysql/en/string-functions.html
>>
>>Tag et kig på SUBSTRING()
>
>
> Eller PHP's egen substr() funktion:
>
> http://dk2.php.net/manual/en/function.substr.php
>

Blot sådan rent praksis - hvis teksten ikke skal bruges andre steder vil
jeg fraråde at bruge "kræfter" på at hive den ud af databasen - det er
unødvendig belastning når MySQL selv har en funktion der klarer sagerne :)

Jeg ved vi er i en PHP gruppe - og mit svar delvis hører hjemme i
databasegruppen ;)

mvh
Johan

---

On 2005-05-17, Johan Holst Nielsen <spam@phpgeek.dk> wrote:
> Blot sådan rent praksis - hvis teksten ikke skal bruges andre steder
> vil jeg fraråde at bruge "kræfter" på at hive den ud af databasen -
> det er unødvendig belastning når MySQL selv har en funktion der klarer
> sagerne :)

Jeg er ikke helt sikker på, hvad du mener med "hvis teksten ikke skal
bruges andre steder", men umiddelbart er der ikke noget galt i at hive
teksten ud af databasen og formattere den med PHP. Naturligvis kan man
forøge performance en smule ved at lade databasen foretage operationen,
men som en klog mand engang sagde: "Premature optimization is the root
of all evil", eller noget deromkring

--
Med venlig hilsen
- Jacob Atzen

---

Jacob Atzen wrote:

> Jeg er ikke helt sikker på, hvad du mener med "hvis teksten ikke skal
> bruges andre steder", men umiddelbart er der ikke noget galt i at hive
> teksten ud af databasen og formattere den med PHP.

Heller ikke, hvis teksten består af 100.000 tegn, om man kun skal bruge
de første 50 ?
Der ville jeg da klart lade MySql stå for arbejdet, når den nu klarer
det så fint.

--
Benny

---

On 2005-05-17, Benny Nissen <news@bennynissen.dk> wrote:
> Heller ikke, hvis teksten består af 100.000 tegn, om man kun skal bruge
> de første 50 ?

Nej, heller ikke i det tilfælde. Der er ikke grund til at gå i gang med
at optimere performance før man oplever, at man har et performance
problem.

--
Med venlig hilsen
- Jacob Atzen

---

>>Heller ikke, hvis teksten består af 100.000 tegn, om man kun skal bruge
>>de første 50 ?
>
>
> Nej, heller ikke i det tilfælde. Der er ikke grund til at gå i gang med
> at optimere performance før man oplever, at man har et performance
> problem.


Jeg vil nu mene det altid er en god ide at optimere sin kode, for hvis
det skal gøres bagefter glemmer man sikkert noget, og det er dobbelt
arbejde. Desuden resulterer det ofte med en masse rode-kode.
Så hellere gøre det ordenligt fra starten.

Blot min mening =)

// Zigma

---

On 2005-05-17, Kasper Leth Jensen <zigma@zigma.dk> wrote:
> Jeg vil nu mene det altid er en god ide at optimere sin kode, for hvis
> det skal gøres bagefter glemmer man sikkert noget, og det er dobbelt
> arbejde.

Nej, det dobbelte arbejde er at foretage "optimeringer" før du ved, at
de er nødvendige. Hvis dit program kører hurtigt nok uden optimeringer,
så er det spildt arbejde at optimere. Hvis dit program kører for
langsomt kan du undersøge, hvor flaskehalsen er og koncentrere dig om
den.

> Desuden resulterer det ofte med en masse rode-kode.
> Så hellere gøre det ordenligt fra starten.

Hvis du ikke kan finde ud af at refaktorere og holde din kode i god
form, så har du større problemer end hvorvidt du kan spare 0.0001 sekund
på at lade databasen foretage substr().

> Blot min mening =)

Og dette var så min

--
Med venlig hilsen
- Jacob Atzen

---

Jacob Atzen wrote:
> On 2005-05-17, Kasper Leth Jensen <zigma@zigma.dk> wrote:
>
>>Jeg vil nu mene det altid er en god ide at optimere sin kode, for hvis
>>det skal gøres bagefter glemmer man sikkert noget, og det er dobbelt
>>arbejde.
>
> Nej, det dobbelte arbejde er at foretage "optimeringer" før du ved, at
> de er nødvendige. Hvis dit program kører hurtigt nok uden optimeringer,
> så er det spildt arbejde at optimere. Hvis dit program kører for
> langsomt kan du undersøge, hvor flaskehalsen er og koncentrere dig om
> den.

Det drejer sig jo ikke om dobbeltarbejde - det drejer sig om hvorvidt
man skal indsætte koden i PHP eller SQL'en. Kan ikke se hvor
dobbeltarbejdet sker i dette tilfælde?

>>Desuden resulterer det ofte med en masse rode-kode.
>>Så hellere gøre det ordenligt fra starten.
>
> Hvis du ikke kan finde ud af at refaktorere og holde din kode i god
> form, så har du større problemer end hvorvidt du kan spare 0.0001 sekund
> på at lade databasen foretage substr().

Ja - nu kender jeg ikke koden. Men kan ikke se det gør den store forskel
at ændre "SELECT foo FROM bar" til "SELECT SUBSTRING(foo,0,50) FROM bar"
og ændre "echo $row['foo']" og ændre "echo substr($row['foo'],0,50)"


>>Blot min mening =)
>
>
> Og dette var så min

Og endnu en blev tilføjet :)

Selvfølgelig har selve hele opbygningen af sitet en vis indflydelse -
hvis andre data fra feltet skal bruges andre steder, vil jeg også
foretrække at formatere det i PHP'en.

mvh
Johan

---

On 2005-05-18, Johan Holst Nielsen <spam@phpgeek.dk> wrote:
> Jacob Atzen wrote:
>> Nej, det dobbelte arbejde er at foretage "optimeringer" før du ved, at
>> de er nødvendige. Hvis dit program kører hurtigt nok uden optimeringer,
>> så er det spildt arbejde at optimere. Hvis dit program kører for
>> langsomt kan du undersøge, hvor flaskehalsen er og koncentrere dig om
>> den.
>
> Det drejer sig jo ikke om dobbeltarbejde - det drejer sig om hvorvidt
> man skal indsætte koden i PHP eller SQL'en. Kan ikke se hvor
> dobbeltarbejdet sker i dette tilfælde?

Ovenstående kommentarer er møntet bredere end det aktuelle tilfælde.

Min hovedpointe er, at man ikke skal tro man vinder noget ved at
optimere performance før man har en indikation, der peger i retning af,
at det er nødvendigt. Argumentationen er, at for tidlig optimering kan
resultere i kode, der er sværere at læse og vedligeholde. Keep it
simple.

Hvis du ligeså fint kan læse en SQL sætning med substr, jamen så gør for
alt i verden det. For mig er det bare simplere, at hive databasefeltet
ud ensartet alle steder jeg bruger det og så arbejde med det i PHP. På
den måde behøver jeg ikke konsultere mine queries for at finde ud af,
hvorvidt min variabel nu indeholder hele feltet eller en del af feltet
eller noget tredje.

--
Med venlig hilsen
- Jacob Atzen

---

Jacob Atzen wrote:
> On 2005-05-18, Johan Holst Nielsen <spam@phpgeek.dk> wrote:
>
>>Jacob Atzen wrote:
>>
>>>Nej, det dobbelte arbejde er at foretage "optimeringer" før du ved, at
>>>de er nødvendige. Hvis dit program kører hurtigt nok uden optimeringer,
>>>så er det spildt arbejde at optimere. Hvis dit program kører for
>>>langsomt kan du undersøge, hvor flaskehalsen er og koncentrere dig om
>>>den.
>>
>>Det drejer sig jo ikke om dobbeltarbejde - det drejer sig om hvorvidt
>>man skal indsætte koden i PHP eller SQL'en. Kan ikke se hvor
>>dobbeltarbejdet sker i dette tilfælde?
>
> Ovenstående kommentarer er møntet bredere end det aktuelle tilfælde.

Okay :) Regnede jeg også med - prøvede bare at før den tilbage dertil,
hvor det hele startede ;)

> Min hovedpointe er, at man ikke skal tro man vinder noget ved at
> optimere performance før man har en indikation, der peger i retning af,
> at det er nødvendigt. Argumentationen er, at for tidlig optimering kan
> resultere i kode, der er sværere at læse og vedligeholde. Keep it
> simple.

Er helt enig - optimering skal ikke ske med hovedet under armen.

> Hvis du ligeså fint kan læse en SQL sætning med substr, jamen så gør for
> alt i verden det. For mig er det bare simplere, at hive databasefeltet
> ud ensartet alle steder jeg bruger det og så arbejde med det i PHP. På
> den måde behøver jeg ikke konsultere mine queries for at finde ud af,
> hvorvidt min variabel nu indeholder hele feltet eller en del af feltet
> eller noget tredje.

Hmm, det synes jeg nu er et dårlig argument... at du skal tjekke SQL'en
er ingen grund til?

2 eksempler for lige at illusterere.

$query = "SELECT felt FROM tabel WHERE foo = bar";
$result = mysql_query($query);
while($row = mysql_fetch_assoc($result)) {
$felt_Subtring = substr($row['felt'],0,50); //de første 50.
/* en masse kode */
echo '<h3>'.$felt_Substring.'</h3>';
/* en masse kode */
}

Det er eksemplet med PHP... med MySQL kan du jo blot navngive dit udtræk
ordentligt - således det giver overskuelighed.

$query = "SELECT SUBSTRING(felt,0,50) as felt_Substring FROM tabel WHERE
foo = bar";
$result = mysql_query($query);
while($row = mysql_fetch_assoc($result)) {
/* en masse kode */
echo '<h3>'.$row['felt_Substring'].'</h3>';
/* en masse kode */
}


Kan ikke se man mister overblikket - og man skal konsultere SQL'en for
at gennemskue det. (Enig - man kunne sagnes undgå den $felt_Substring
for at optimere performance ;) nu vi er igang - mere for at gøre det
nemmere illusteret).


mvh
Johan

---

On 2005-05-18, Johan Holst Nielsen <spam@phpgeek.dk> wrote:
> Hmm, det synes jeg nu er et dårlig argument... at du skal tjekke SQL'en
> er ingen grund til?
>
> 2 eksempler for lige at illusterere.
>
> $query = "SELECT felt FROM tabel WHERE foo = bar";
> $result = mysql_query($query);
> while($row = mysql_fetch_assoc($result)) {
> $felt_Subtring = substr($row['felt'],0,50); //de første 50.
> /* en masse kode */
> echo '<h3>'.$felt_Substring.'</h3>';
> /* en masse kode */
> }
>
> Det er eksemplet med PHP... med MySQL kan du jo blot navngive dit udtræk
> ordentligt - således det giver overskuelighed.
>
> $query = "SELECT SUBSTRING(felt,0,50) as felt_Substring FROM tabel WHERE
> foo = bar";
> $result = mysql_query($query);
> while($row = mysql_fetch_assoc($result)) {
> /* en masse kode */
> echo '<h3>'.$row['felt_Substring'].'</h3>';
> /* en masse kode */
> }
>
>
> Kan ikke se man mister overblikket - og man skal konsultere SQL'en for
> at gennemskue det. (Enig - man kunne sagnes undgå den $felt_Substring
> for at optimere performance ;) nu vi er igang - mere for at gøre det
> nemmere illusteret).

Selv i ovenstående tilfælde har jeg nemmere ved at læse, hvad koden gør
i første tilfælde, fordi det er gjort eksplicit, at der bliver foretaget
en substr() operation. I det andet tilfælde er substr() gemt væk i
queryen og dermed er den nemmere at overse.

--
Med venlig hilsen
- Jacob Atzen

---

Jacob Atzen wrote:

> Nej, heller ikke i det tilfælde. Der er ikke grund til at gå i gang med
> at optimere performance før man oplever, at man har et performance
> problem.

Jo, men det er vel ikke at optimere, men at bruge den rigtige kode /
funktion fra starten ?

Hvis man alligevel skal til at skrive en select-sætning i sql og
bagefter noget php-kode til at vise dataene, så kan man vel lige så godt
bruge mysql-funktionen som php-funktionen ?

--
Benny

---

On Tue, 17 May 2005 23:03:38 +0200, Benny Nissen <news@bennynissen.dk>
wrote:

>Hvis man alligevel skal til at skrive en select-sætning i sql og
>bagefter noget php-kode til at vise dataene, så kan man vel lige så godt
>bruge mysql-funktionen som php-funktionen ?

Det må afhænge af situationen.

Hvis der er tale om tekst, der bruges flere gange undervejs, eller i
øvrigt kan justeres forskelligt afhængigt af konteksten, så vil jeg
også foretrække at gøre det i PHP. Det kan tænkes, at man vil angive
lidt af teksten som en teaser, men stadigvæk have et længere stykke
som en title-værdi i HTML'en.

Det kan let blive noget uoverskueligt rod, hvis man vil flytte
logikken forskellige steder hen så der både laves behandlinger og
mellemresultater i MySQL og i PHP.

Men nu ved vi jo heller ikke, om der er tale om tekststykker på
millioner af tegn.

--
- Peter Brodersen

---

Peter Brodersen wrote:
> On Tue, 17 May 2005 23:03:38 +0200, Benny Nissen <news@bennynissen.dk>
> wrote:
>
>
>>Hvis man alligevel skal til at skrive en select-sætning i sql og
>>bagefter noget php-kode til at vise dataene, så kan man vel lige så godt
>>bruge mysql-funktionen som php-funktionen ?
>
> Det må afhænge af situationen.

Det er rigtigt.

> Hvis der er tale om tekst, der bruges flere gange undervejs, eller i
> øvrigt kan justeres forskelligt afhængigt af konteksten, så vil jeg
> også foretrække at gøre det i PHP. Det kan tænkes, at man vil angive
> lidt af teksten som en teaser, men stadigvæk have et længere stykke
> som en title-værdi i HTML'en.

Jeg er enig i dette tilfælde. Diskussionen kom fra mit indlæg, hvor jeg
prøvede at gøre det klart at SUBSTRING i MySQL burde bruiges "hvis
teksten ikek skal bruges andre steder" - jeg ved det måske var lidt
uklart :) Men håber det er forklaret nu.

> Det kan let blive noget uoverskueligt rod, hvis man vil flytte
> logikken forskellige steder hen så der både laves behandlinger og
> mellemresultater i MySQL og i PHP.

Helt enig.

> Men nu ved vi jo heller ikke, om der er tale om tekststykker på
> millioner af tegn.

Nej - men tit ender det jo med at data bliver en del større en man nogle
gange regnede med - hvis det starter som et hobbyprojekt og bliver
(semi)professionelt - så burde samme kode jo gerne stadig kunne bruges :)

mvh
Johan

---

Jacob Atzen wrote:
> On 2005-05-17, Benny Nissen <news@bennynissen.dk> wrote:
>
>>Heller ikke, hvis teksten består af 100.000 tegn, om man kun skal bruge
>>de første 50 ?
>
> Nej, heller ikke i det tilfælde. Der er ikke grund til at gå i gang med
> at optimere performance før man oplever, at man har et performance
> problem.

Det vil sige der er ingen grund til at optimere en løkke der køres
igennem 1000000 gange men allerede har gjort arbejde efter 100
gennemløb, hvis der ikke er et performance problem?

Det her drejer sig jo om noget så simpelt som man skal bruge SELECT
SUBSTRING... eller om man skal bruge substr() i PHP - rent faktisk vil
jeg mene den "optimerede" version er meget nemmere i dette tilfælde.
Hvis optimeringen omfattede en masse arbejde ville jeg være enig - men
slet ikke i dette tilfælde.

mvh
Johan

---

Johan Holst Nielsen wrote:

> Det vil sige der er ingen grund til at optimere en løkke der køres
> igennem 1000000 gange men allerede har gjort arbejde efter 100
> gennemløb, hvis der ikke er et performance problem?

Det er da ikke at optimere, men at skrive defekt kode i første omgang

Der er i min verden forskel på at skrive defekt kode (altså kode med
meget store preformance-problemer), og så kode, med små detaljer, der
kan gøre det hele bare lidt hurtigere.

Eks:
$foo = "text1";
$bar = "text2";
$myfoobar = $foo.$bar;
echo $myfoobar;

I ovenstående kan linie 3 undlades ved at ændre linie 4 til:
echo $foo.$bar;

Man sparer en variabel (der fylder i serverens hukommelse), og kan
sparer en instruktion (linie 3). Ikke det helt store, men i en løkke kan
det godt hjælpe lidt på tiden. Det kalder jeg optimering.


--
Benny

---

Benny Nissen wrote:
> Johan Holst Nielsen wrote:
>
>> Det vil sige der er ingen grund til at optimere en løkke der køres
>> igennem 1000000 gange men allerede har gjort arbejde efter 100
>> gennemløb, hvis der ikke er et performance problem?
>
> Det er da ikke at optimere, men at skrive defekt kode i første omgang

Naah - afhænger af situationen...
Forstil dig følgende du skal finde en streng i et array med en masse
strenge (lover ikke det er det perfekt eksempel).

<?php
//$foo er et array med en masse data
$bar = 'pruh hest'; //streng jeg gerne vil finde

for($i=0;$i<sizeof($foo);$i++) {
if(strstr($foo[$i],$bar)!==false) {
echo 'Juhu jeg fandt det';
}
}
?>

Hvis du nu smed et break ind efter echo'et er det jo optimering - og det
er der jeg vil hen.

> Der er i min verden forskel på at skrive defekt kode (altså kode med
> meget store preformance-problemer), og så kode, med små detaljer, der
> kan gøre det hele bare lidt hurtigere.

Jah - men bare lidt hurtigere kan hurtigt blive MEGET hurtigere - f.eks.
hvis ens site bliver en større system end forventet - eller der
pludselig er meget mere data :)

>
> Eks:
> $foo = "text1";
> $bar = "text2";
> $myfoobar = $foo.$bar;
> echo $myfoobar;
>
> I ovenstående kan linie 3 undlades ved at ændre linie 4 til:
> echo $foo.$bar;

Enig - i dette tilfælde skal der EKSTREMT mange besøgende til før det
bliver et problem.

>
> Man sparer en variabel (der fylder i serverens hukommelse), og kan
> sparer en instruktion (linie 3). Ikke det helt store, men i en løkke kan
> det godt hjælpe lidt på tiden. Det kalder jeg optimering.

Igen - det er svært - forskellen mellem performance og defekt kode kan
blive ret lille ud fra din tolkning. En ting som på et site der kun har
10 besøgende er ikke en fejl - men det på et site med 10.000 godt kan
være en fejl? Er det således det skal forståes? (Eksemplet med løkken er
vel en mulighed - hvor det ville give en virkning med mange samtidige
besøgende).

mvh
Johan

---

On Wed, 18 May 2005 13:29:58 +0200, Benny Nissen <news@bennynissen.dk>
wrote:

>Eks:
>$foo = "text1";
>$bar = "text2";
>$myfoobar = $foo.$bar;
>echo $myfoobar;
>
>I ovenstående kan linie 3 undlades ved at ændre linie 4 til:
>echo $foo.$bar;
>
>Man sparer en variabel (der fylder i serverens hukommelse), og kan
>sparer en instruktion (linie 3). Ikke det helt store, men i en løkke kan
>det godt hjælpe lidt på tiden. Det kalder jeg optimering.

Hvis man gør det udelukkende af hensyn til optimering (og ved, at de
tekststrenge ikke er så lange), så synes jeg stadigvæk, det kan være
noget rod. Måske optræder ovenstående fire linjer langt fra hinanden,
og måske kan mere sigende variabelnavne hjælpe på forståelsen, når en
anden person senere skal rette i koden.

Eks:
$birthday = "121212";
$control = "1212";
$cpr = $birthday.$control;
echo $cpr;

Hvis cpr-nummeret fx skal optræde mange gange på siden atomisk, kan
det give bedre mening at benytte sig af $cpr. Det giver færre mulighed
for forskellige præsentationer, og det er muligt ét centralt sted at
rette $cpr = $birthday.$control; til $cpr = $birthday."-".$control;

Igen, det med at spare "et par bytes" er en fin tanke, men den er ofte
både ubrugelig og forfejlet. Ubrugelig, fordi et par bytes ikke gør
nogen forskel, heller ikke med massive brugermængder (idet der typisk
både er mere cpu-intensive og ram-forbrugende opgaver undervejs), og
forfejlet, fordi der er bedre steder at spare i sit setup i første
omgang. Bruger man virkelig curl, mcrypt, gd, imap, tidy, mhash,
etc.-extensions? Er der ingen grund til at hver evige eneste
php-instans skal have de extensions loaded, eller kan man klare sig
med dl() i de enkelte tilfælde, hvor der er brug for dem? (hvis vi
lige ser bort fra multithreadede webservere)

--
- Peter Brodersen

---

Peter Brodersen wrote:
> On Wed, 18 May 2005 13:29:58 +0200, Benny Nissen <news@bennynissen.dk>
> wrote:
>
>
>>Eks:
>>$foo = "text1";
>>$bar = "text2";
>>$myfoobar = $foo.$bar;
>>echo $myfoobar;
>>
>>I ovenstående kan linie 3 undlades ved at ændre linie 4 til:
>>echo $foo.$bar;
>>
>>Man sparer en variabel (der fylder i serverens hukommelse), og kan
>>sparer en instruktion (linie 3). Ikke det helt store, men i en løkke kan
>>det godt hjælpe lidt på tiden. Det kalder jeg optimering.
>
>
> Hvis man gør det udelukkende af hensyn til optimering (og ved, at de
> tekststrenge ikke er så lange), så synes jeg stadigvæk, det kan være
> noget rod. Måske optræder ovenstående fire linjer langt fra hinanden,
> og måske kan mere sigende variabelnavne hjælpe på forståelsen, når en
> anden person senere skal rette i koden.

Helt enig.

> Eks:
> $birthday = "121212";
> $control = "1212";
> $cpr = $birthday.$control;
> echo $cpr;

Rigtigt - jeg ville være det samme i dette tilfælde :)

> Hvis cpr-nummeret fx skal optræde mange gange på siden atomisk, kan
> det give bedre mening at benytte sig af $cpr. Det giver færre mulighed
> for forskellige præsentationer, og det er muligt ét centralt sted at
> rette $cpr = $birthday.$control; til $cpr = $birthday."-".$control;

Enig.

> Igen, det med at spare "et par bytes" er en fin tanke, men den er ofte
> både ubrugelig og forfejlet. Ubrugelig, fordi et par bytes ikke gør
> nogen forskel, heller ikke med massive brugermængder (idet der typisk
> både er mere cpu-intensive og ram-forbrugende opgaver undervejs), og
> forfejlet, fordi der er bedre steder at spare i sit setup i første
> omgang. Bruger man virkelig curl, mcrypt, gd, imap, tidy, mhash,
> etc.-extensions? Er der ingen grund til at hver evige eneste
> php-instans skal have de extensions loaded, eller kan man klare sig
> med dl() i de enkelte tilfælde, hvor der er brug for dem? (hvis vi
> lige ser bort fra multithreadede webservere)

Jeg er enig i dine konklusioner - men mener ikke det er her den
optræder. Det drejer sig om hvorvidt man skal allokere plads til data
der aldrig nogensinde skal bruges - og det var det jeg var "imod". Hvis
man på en artikel website ønsker at der skal være en oversigt med
artikler - hvor de første 50 karakterer af artiklen skal vises som
appetitvækker - så er der ingen som helst grund til at hive de
resterende karakterer ud fra databasen. Det er både rent
performancemæssigt og rent logisk. Det vil ikke give ændringer rent
"overskuelsesmæssigt" - så det burde ikke være et problem :)

mvh
Johan

---

On 2005-05-18, Johan Holst Nielsen <spam@phpgeek.dk> wrote:
> Det vil sige der er ingen grund til at optimere en løkke der køres
> igennem 1000000 gange men allerede har gjort arbejde efter 100
> gennemløb, hvis der ikke er et performance problem?

Nej, der er ikke grund til at ændre på den, hvis det eneste formål er,
at man ikke vil udsætte computeren for unødigt arbejde. Computeren er
ligeglad med hvad du sætter den til at lave. Brugeren af dit program er
ligeglad med om du optimerer 999900 gennemløb væk, hvis applikationen
svarer hurtigt nok. Så hvad har du vundet ved at eliminere de ekstra
gennemløb?

Der kan sagtens være grunde til at ændre på koden i dit eksempel. F.eks.
at koden bliver lettere at forstå.

--
Med venlig hilsen
- Jacob Atzen

---

Jacob Atzen wrote:
> On 2005-05-18, Johan Holst Nielsen <spam@phpgeek.dk> wrote:
>
>>Det vil sige der er ingen grund til at optimere en løkke der køres
>>igennem 1000000 gange men allerede har gjort arbejde efter 100
>>gennemløb, hvis der ikke er et performance problem?
>
> Nej, der er ikke grund til at ændre på den, hvis det eneste formål er,
> at man ikke vil udsætte computeren for unødigt arbejde. Computeren er
> ligeglad med hvad du sætter den til at lave. Brugeren af dit program er
> ligeglad med om du optimerer 999900 gennemløb væk, hvis applikationen
> svarer hurtigt nok. Så hvad har du vundet ved at eliminere de ekstra
> gennemløb?

Ja, men brugerne på websitet er måske ikke ;)

> Der kan sagtens være grunde til at ændre på koden i dit eksempel. F.eks.
> at koden bliver lettere at forstå.

Rigtigt - men så er vi nok ude i en smagssag - om man ønsker det skal
stå i SQL'en eller PHP'en. Jeg mener nu stadig at det er problematisk at
hente dataene ud fra databasen, hvis den ikke skal bruges (ligeledes
synes jeg ikke om SELECT * statements). (Der kan så argumentere med at
SELECT * i de fleste tilfælde smadrer overblikket i koden - da man skal
have styr på databasenstrukturen, for at vide hvad der sker).

Det er nok i sidste ende mere en smagssag end alt muligt andet.

mvh
Johan

---

On 2005-05-18, Johan Holst Nielsen <spam@phpgeek.dk> wrote:
> Jacob Atzen wrote:
>> On 2005-05-18, Johan Holst Nielsen <spam@phpgeek.dk> wrote:
>> Nej, der er ikke grund til at ændre på den, hvis det eneste formål er,
>> at man ikke vil udsætte computeren for unødigt arbejde. Computeren er
>> ligeglad med hvad du sætter den til at lave. Brugeren af dit program er
>> ligeglad med om du optimerer 999900 gennemløb væk, hvis applikationen
>> svarer hurtigt nok. Så hvad har du vundet ved at eliminere de ekstra
>> gennemløb?
>
> Ja, men brugerne på websitet er måske ikke ;)

Det var dem jeg mente da jeg skrev "Brugeren af dit program...". I det
tilfælde, at applikationen ikke svarer hurtigt nok er det relevant at
kigge på optimering af performance.

--
Med venlig hilsen
- Jacob Atzen

---

Jacob Atzen wrote:
> On 2005-05-17, Johan Holst Nielsen <spam@phpgeek.dk> wrote:
>
>>Blot sådan rent praksis - hvis teksten ikke skal bruges andre steder
>>vil jeg fraråde at bruge "kræfter" på at hive den ud af databasen -
>>det er unødvendig belastning når MySQL selv har en funktion der klarer
>>sagerne :)
>
>
> Jeg er ikke helt sikker på, hvad du mener med "hvis teksten ikke skal
> bruges andre steder", men umiddelbart er der ikke noget galt i at hive
> teksten ud af databasen og formattere den med PHP.

Nej - der er ikke noget galt i det - men synes blot ikke det virker
gennemtænkt - men igen det afhænger af diskutionen - jeg bringer det
blot på banen da jeg synes det er vigtig.

"hvis teksten ikke skal bruges andre steder" mener jeg blot - hvis du
har et tekstfelt med XXXX antal tegn og kun skal bruge de første 20-30
stykker, ville det være dumt at hente alt sammen ud - og bagefter bruge
en ekstra funktion i PHP til at forkorte en tekst, som lige så godt
kunne være forkortet ved dataudtrækket.

> Naturligvis kan man
> forøge performance en smule ved at lade databasen foretage operationen,
> men som en klog mand engang sagde: "Premature optimization is the root
> of all evil", eller noget deromkring

Ja - men for tidlig optimering er altid individuelt - i dette tilfælde
synes jeg det citat er helt malplaceret, ud fra den diskution jeg
(prøvede) at forklare.

mvh
Johan