Vælg første række i array()

reset($alle);
$resultat=next($alle);

<ole>

Hvis array'et er tal-indekseret, står de tallenes rækkefølge ... det giver ingen mining at tale om andre rækkefølger. Det må du vist forklare nærmere  :)

/mvh
</bole>

Ah ja, det lagde jeg ikke lige mærke til. Glem mit svar så :)

Hehe ... koden, mtrolle har skrevet, giver i det hele taget ingen mening - så en uddybning er yderst påkrævet  ;o)

Jeg laver en sortering af arrayet via arsort().
På den måde vil 5 kunne stå øverst, hvis indholdet af alle[5] sorteringsmæssigt set, ligger over 1.
current giver noget som ligner det jeg forespørger.

Undersøger det nærmere pt. :)

Nej, mtrolle ... det, du skriver, giver stadig ingen mening  :)

Hvordan ser dit array ud? Det ser med garanti ikke ud, som du viser

Jo det gør det.. Det giver da mening hele vejen igennem ;)

mtrolle vil gerne have den række i 'alle' med det højeste index. (regner jeg da med), og så kan du vel bare lave en

$alle = ksort($ditarray);
echo end($alle); //Udskriver "farvel tekst"

>wicez
Præcis :)
Jeg har bare omvendt det med krsort eller hvad den nu hedder, men med end er det nok mindre krævende for serveren :)

Bortset fra det fandt jeg frem til array_multisort som kan det jeg ønsker 100% :)
Men wicez, smid et svar med :) Så deler i.

Det glæder mig at det lykkedes i sidste ende ;o)

Nå sådan.. Jeg troede bare at du ville have den første række der blev gemt, og det kan man ikke med numerisk index.

Du må lige forklare det noget bedre næste gang, i stedet for at komme med et tvetydigt stykke kode ;)

Det er altid meget mere logisk når man selv ved, hvad man vil :)

wicez >> med al respekt ... nej, det giver ikke megen mening  :)

Godt nok virker det, somom det giver mening - men det er kun fordi, PHP på mange områder er et ret loose/sloppy/ustringent sprog ... ikke mindst hvad angår arrays.

Elementerne i et tal-indekseret array har én rækkefølge - den deres indeks angiver. At PHP så roder streng- og tal-indekserede arrays sammen til én grød, er en helt anden ting ... det savner enhver sund logik og ulogisk kode er der sjældent gode grunde til at bruge.

Den 'rækkefølge' du ser i en var_dump() af et tal-indekseret array har du intet at bruge til - bortset lige fra funktionen end()  ;o)

Det forstår jeg godt olebole, og jeg giver dig helt ret i, at det ikke giver nogen mening. Men ikke desto mindre gav mtrolles spørgsmål mening for, om ikke andre, mig ;o)

olebole>
kig på array_multisort(), sort(), rsort() osv.
Hvorfor mener du, at man ikke må skulle kunne lave et nyt indeks af et array?

For min skyld må du gøre, hvad du vil ... men der er intet somhelst logisk i at bytte rundt på tal-keys. Det har aldrig været meningen i noget sprog - og det må henregnes under sprog-bugs, når man kan gøre det.

Da man altid henter et element i et tal-indekseret array med dets indeks, er det derudover ret sort at begynde at bytte rundt på den 'tilfældige' rækkefølge elementerne har ved f.eks. var_dump().

Det eneste, der er at bruge den slags til, er funktionen end() - for du traverserer vel ikke tal-indekserede arrays med en foreach-løkke?
En alm. for-løkke performer bedre, så det er metoden, man traverserer tal-indekserede arrays med ... og så er det mere end svært at se, hvad årsagen til at rode med 'rækkefølgen' skulle være  ;o)

Mit problem ligger i, at MySQL ikke kan følge med pga. min ORDER plus jeg skal bruge tal fra flere forskellige rækker i databasen i min sortering. Derfor har det været nødvendigt for mig, at lave sorteringen i PHP.
Da jeg har behov for at sortere efter en prioritet og et procenttal, kræver det at der gøres via et multiarray.
Jeg har gjort det, at jeg via foreach() laver to arraies (er det sådan i flertal?), hvorefter jeg benytter array_multisort().

Hvis du mener det er helt forkert, vil jeg da gerne vide, hvordan du ellers ville gøre det, så mit script kan blive så optimeret som muligt.

Måske spm. skulle ligge i mysql kategorien, for at få fundet den korrekte query i stedet?

Jamen problemet er jo netop, at MySQL ikke kan klare udregningerne. Derfor er det et PHP spørgsmål.

?
Nu er jeg ikke lige helt med på hvad du spørger efter, læste mest din kommentar, før min første, og jeg ville da gerne ha' udpenslet hvilken "query sortering" du ønsker, der ikke kan hamle op med at du først laver en query, laver et array, og så sorterer med PHP?

Så er der noget, der tyder på, vi taler om to forskellige ting. At rette på 'rækkefølgen' i et tal-indekseret array - via ksort() - giver ikke mening ... men at sortere et multidimensionalt array giver ganske god mening  :)

Det er dog afgjort min erfaring, at det altid er langt hurtigere at lade MySQL om den slags. At du har problemer, kunne f.eks. tyde på mangelfuld indeksering af DB'en - i forhold til dine queries(?)

Nu ved jeg, du kører en del 'DB-tunge' sites, så måske du i det hele taget kunne 'tune' dine sites/queries og få MySQL til at køre bedre:

1. Husker du at indeksere dine tabeller i forhold til dine queries?
2. Undlader du at bruge * i dine queries - med mindre, det er _absolut_ nødvendigt?
3. Husker du at bruge 'LIMIT 1' i dine select- og update-queries, når du ved, du kun skal hente én række?

- det er blot nogle få helt basale ting, du skal sørge for er i orden. Derudover er der en masse andre ting, du kan gøre for at optimere performance, men de tre ting er helt grundlæggende 'musts'  :)

Jeg laver en procent beregning.
Som det er nu i min struktur, skal der hentes data fra 3 forskellige databaser for at lave denne beregning.
Det lyder uvirkeligt, ved det godt, men det er virkelig nødvendigt at foretage beregningen uden for mysql.

- njaahhh ... lad mig lige halvgardere med et 'næsten'  :)
"Det er dog afgjort min erfaring, at det næsten altid er langt hurtigere at lade MySQL om den slags"

Fra tre DB's eller fra tre tabeller?
Er det mange enslydende queries, der evt. kan caches?
Er der fidus i at leve en ekstra DB/tabel?

Det er lidt svært, når man ikke kender projektet  :)

olebole>
1. ja. Dagligt køres der en optimize på DB'en og al indexering er lavet samlet og hver for sig på kryds og tværs. Det er på et punkt, hvor der ikke kan gøres meget mere.
2. * benyttes ganske få steder, hvor det er absolut nødvendigt ;)
3. Pt. har limit 1 ved select ikke været en mulighed. Ved updates gøres det udelukkende via id'et på rækken, altså primery key, så der burde LIMIT 1 jo ikke have betydning (hvad jeg ved af).

Vi har knoklet med optimering af alle vores database strukture og ette er næste tænkelige script.

olebole>
Ja, jeg kan desværre ikke udtale mig om projektet, det ville gøre det hele så meget lettere :)

Der er ikke enslydende queries i dette script. Pt. benyttes SQL_NO_CACHE, således der ikke skabes cache på hver eneste forespørgelse, da der laves opdateringer hele tiden, hvilket gør at cachen alligevel bliver smidt væk.

og ja, jeg talte om 3 tabeller :) ups.

Hmmm .... 'LIMIT 1' i en WHERE-klausul, hvor der spørges på en primary .... det ved jeg zq ikke positivt. Jeg limitterer altid selv, når det er muligt - 'tampon, bind og gummibukser' :) - men om det reelt er en fordel på en primary key, er jeg ikke 100% sikker på.
Ellers ser det jo ikke ud til, du har de store, klassiske performance fejl  :)

Umiddelbart ville jeg stadig mene, MySQL ville være en fordel at bruge - men det kan vel også være et spørgsmål om, hvor belastet din MySQL-server er i forhold til din alm. webserver(?)

Det er jo nemlig det :)
Det er et meget tungt system og som du selv skriver tidligere arbejder jeg med en del DB-tunge sites.
I alt fald har min serveransvarlige "påbudt" mig at begynde at kigge på optimering af PHP koden og få så meget MySQL ud i PHP'en som muligt.
Jeg knokler på med array_multisort, tror helt sikkert det er vejen frem, men måler efter på serveren ;)

Tusind tak for snakken :)

- selvtak ... og foreløbigt lyder det, somom jeg godt kunne finde udaf at drikke øl med din serveransvarlige  ;o)

Håber, du kommer godt videre med projektet ... og ellers kender du jo adressen  ;D