mysql results funktion

Jeg kan ikke se den store forskel i at lave et normal while-loop og så din function.

Du selecter din DB hver gang du laver en query. Det kunne man måske leve med hvis ens kode flintrede rundt i forskellige databaser.

Du laver et foreach-loop inden i et while-loop. Uden at teste vil jeg tro at du i bedste fald kører loopet igennem med antal rækker * antal rækker. Men det er sikkert en detalje der hurtigt kunne rettes. Men jeg synes stadig du lægger en unødvendig frakke uden på et normalt loop uden at der er nogen synlig gevinst.

Dertil kommer at jeg har et problem med kan parse resultatet fra en query så fleksibelt som muligt.. I mine øjne er der ikke tale om at parse (i betydningen undersøge/analysere), men om at sætte resultatet ind i en tabel. Hvordan vil du reagere hvis det er nødvendigt at handle på indholdet af 'foo' eller 'bar'. Hvis f.eks. 'foo' med værdien -1 skal springes over eller highlightes?

Det med db'en er for så vidt heller ikke nødvændig, det var nu bere for at have den med, men den kan skrottes.

foreach loopet er for at man ikke er nød til at kende navnet på "$row"-variablen, men den er som du siger, overhovedet heller ikke nødvendig.

Mht parsing - har åbenbart ikke lige haft den rette viden om hvad det betød, troede egentligt bare det var at "behandle/præsentere en datastrøm" - jeg ved ikke lige hvordan jeg bedre skal forklare det, men så kunne man da lige blive det klogere :)

Det behøver ikke nødvendigvist at være en tabel, det kan i princippet være alt.

I første omgang er det egentligt bare meningen at det skulle være en simpel måde at præsentere data der er hentet fra en database, om det er en menu, eller noget tekst, eller en poll, bør egentligt at være underordnet.




Det kunne jo være rigtigt fedt at lave noget som kunne reagere på resultatet, eller f.eks. tilføje mulighed for at funktionen selv kunne fylde kollonner, hvis der var et ukendt nummer af disse, eller noget i den retning. Men som sagt er det nu egentligt bare for at rode lidt rundt jeg laver det her, så der er ikke rigtigt nogen krav til funktionen, som vel også sagtens kunne have været en class.
Idéen til at starte med var at lave en enkel funktion, som kunne præsentere al data, i stedet for enten at skrive et whileloop, med queries, eller en ny funktion, hver eneste gang man skal plukke lidt data ud.

<ole>

Hvis man ikke kender antallet af kollonner, så kan man vist roligt sige, man "bare roder"  *o)

Er der i øvrigt en årsag til at bruge mysql_fetch_array? Såvidt jeg kan se, bruger du slet ikke dens talindekserede array, så mon ikke du bør bruge mysql_fetch_assoc i stedet?

/mvh
</bole>

#3 "$arrt" - variablen specificerer MYSQL_ASSOC (default) eller MYSQL_NUMROW, hvis den er defineret i funktionskaldet.
Du har ret i at den i øjeblikket ikke bruges, jeg smed den ind i tilfælde af at funktionen evt. blev udvidet til selv at kunne smide data ind imellem nogle seperatorer, så man med meget lidt kode eksempelvis kunne outputte nogle store tabeller.
Set i retrospekt er der nok ikke megen brug for det, for det er sjældent at man outputter al dataen i en tabel, så du har helt ret.
Men som sagt, er mysql_fetch_array som default i min funktion begrændset til MYSQL_ASSOC.

function mysql_p($query, $content, $prefix = "", $suffix = "", $arrt = "MYSQL_ASSOC") {
while ($row = mysql_fetch_array($result, $arrt)) {

men jo, man kan da spare lidt kode,ved bare at definere den som ASSOC fra starten.


Er der egentligt nogen forskel i performance på associative arrays ift. talindekserede arrays? Ummidelbart har jeg en idé om at talindekserede arrays er en lillesmule hurtigere, men jeg aner det ikke.

Det kommer i høj grad an på, hvordan de bruges - og til hvad. Der er f.eks. ret meget forskel på for og foreach

forskel i performance på associative arrays ift. talindekserede arrays?

I gamle dage (med 8-bit CPU'er og adressebus) kunne det have stor betydning om en variabel var defineret som tegnet "0" eller tallet nul. Skulle variablen bruges til det ene eller andet skulle den castes (ændre type) inden brugen. I dag er fortolkere som php så intelligente at de caster on-the-fly og CPU'ernes clock-frekvens så hurtig at det nærmer sig et akademisk spørgsmål.

Æhem - tror jeg! Jeg vil i hvert fald lægge større vægt på kodens læsbarhed end akademiske nanosekunder.

#5 man kan vel ikke bruge et associativt array direkte i et for loop?
Foreach kan vel bruges med alle typer arrays.

Er der altid stor forskel på for og foreach, kan man f.eks. sige at det i alle tilfælde er bedre at bruge for end foreach, eller kommer det an på om det er associative, eller talindekserede, eller hvordan de bruges/misbruges?

#6 hehe, yeah. Jeg forstillede mig også at foreskellen er så lille at der skal nogle ret seriøse arrays til for at gøre nogen mærkbar forskel, og noget så stort arbejder jeg slet ikke i, så fra min kodnings synspunkt er det ret irrelevant, men man kan ligeså godt få fakta på plads, før man danner sig dårlige vaner. Under alle omstændigheder, agter jeg også at holde mig til associative arrys, så længe data ikke skal behandles automatisk af et script.

det kan godt være at der ikke umiddelbart er forskel at mærke på for kontra foreach, men ved større array og flere (mange flere) brugere på én server (webhoteller o.l.) vil det nok kunne mærkes...

-> #7 - du KAN godt bruge en for-løkke på et ass. array - du kan hente keys ud med array-keys :)

En god regel, som ikke kun knytter sig til programmering, lyder: "Alt, hvad man gør/bruger, bør være velovervejet og velbegrundet i forhold til den aktuelle situation og kontekst".

Folk med indsigt i den danske folkesjæl vil nok argumentere for, at reglen lyder ganske udansk og ude af takt med folkesjælden. Det gør den dog ikke spor dårligere  *D

Har du en god grund til at bruge et associativt array fremfor et talindekseret, bør du bruge et associativt. Ellers bør du bruge den mere simple konstruktion.

Har du en god grund til at bruge en foreach-løkke fremfor en for-løkke, bør du bruge en foreach. Ellers bør du bruge den simplere for-løkke.

Naturligvis er læselighed en ikke uvigtig parameter, men sålænge læseligheden ikke forringes væsentligt, bør man vælge den simpleste løsning til den enkelte opgave.

Og for lige at præcisere: en for-løkke er velegnet til talindekserede, mens en foreach er velegnet til associative arrays. Man kan sagtens lave krumspring, der vender op og ned på anvendelserne af array- og/eller løkketyper - men der skal som altid være en god grund  =)

Alt, hvad man gør/bruger, bør være velovervejet og velbegrundet i forhold til den aktuelle situation og kontekst

Kære ole: Gælder den ikke i alle livets forhold? Skrive brev, køre bil, elske med konen, gå i bad, på arbejdet osv osv?

Lige præcis, men det ville nok hurtigt føre debatten for vidt i disse spalter  *o)

Jeg har aldrig set en person - et fotografi eller et spejlbillede af en - som har kunnet leve op til den ellers ret elementære grundregel.

Når jeg kikker i kode ude på nettet eller taler med folk om deres kode her på E, får jeg det indtryk, at kode meget ofte er yderst sparsomt overvejet og tyndt begrundet.

Prøv f.sks. at surfe med en Explorer, der er sat til at melde enhver scriptfejl. Det er ved at være undtagelsen fra reglen, når man kan se et site uden fejlmeddelelser. Den slags kan ret let undgås ved brug af ganske almindelige tanker hos udviklere(n)  *o)

Jeg tror at det er på tide at få lukket denne tråd, tak for alle jeres inputs, smid et svar jer der vil ahve point, så lukker jeg den inden for den næste uge :)

Jeg samler ikke på points, så det må være andres  =)

jeg springer over

Jeps - jeg lukker, der var ingen der ville have point.

Endnu en gang; tak for jeres inputs :)