Die X kan ik gerust met php uitrekenen nadat ik 2 gegevens uit db haal, maar wat als ik die X wil aflopend/oplopend weergeven? Moet ik die gegevens dan toch in de db wegschrijven of kan ik het gewoon met php doen?
Het lijkt mij dat je hier ASP of Cobol voor nodig hebt.

Waar heb je het over???
USERS
id (sleutel)
nickname (unique constraint)
kills (RG)
deaths (RG)
ratio (X - procesgegeven)


<?php

   if($deaths==0)
   {
        $ratio=$kills;
   }else{
        $ratio=$kills/$deaths;
   }
?>


Ik wil dus mijn tabel/spelerslijst meer fair sorteren, volgens ratio aflopend

Momenteel doe ik dat door ratio up te daten net als ik die bepaald heb, en daarna in de vorm van de tabel uitgieten, maar de procesgegevens mogen niet in de db voorkomen heb ik gelezen, dus zit ik nu met een raadsel =)
Stap 1: Vergeet PHP, daar heeft jouw database en/of datamodel 100x niks mee te maken. Je probeert nu een probleem op te lossen die niet bestaat. Sorteren heeft namelijk helemaal niets te maken met het datamodel en nog minder met welke programmeertaal dan ook.

Ga normaliseren en ga dus uitzoeken welke data je allemaal tot je beschikking hebt en wat je allemaal nodig hebt. Een ratio is bv. de som ((2 * kills) + (3 * deaths)). Het is dus volkomen onzinnig om ratio op te slaan, die heb je namelijk al. Even rekenen en klaar is kees. Op de uitkomst kun je ook gewoon sorteren, dat is een functie die SQL ook biedt.

Tijdens het normaliseren mag je dus nooit gaan bedenken hoe je iets in PHP, Java of Cobol gaat aanpakken, dat is nog minder belangrijk dan welke soap er vanavond op de tv zal zijn.
normalisatie was nog in progres,ah dus zo

SELECT * FROM `users` ORDER BY kills/deaths DESC


dat ik het niet direct geprobeerd had, bedankt om mij erop te wijzen


edit: moet toch nog controlestructuur gebruiken, anders zet hij de gebruikers met 0 deaths gewoon onderaan
Je bent nog niet klaar met normaliseren maar je bent al wel code aan het schrijven? Alvast veel succes toegewenst met debuggen, daar ga je vast nog héél veel tijd in steken. Jouw aanpak is namelijk dé manier om een berg bugs te aan te maken.

En die gore backticks `, dat zal een tikfoutje zijn? Of wil je nog meer bugs hebben?
niet echt coden, was gewoon die log bestandje aan het onderzoeken,
(en in dit geval was ik vergeten dat ik met sql ook kon gaan rekenen, en dus wist ik geen raad meer met ratio)

het onnodige aan het opschonnen,
analyzeren welke gegevens ik allemaal nodig heb,

is niet echt logisch om eerst te normaliseren en daarna telkens nieuwe attributen te ontdekken die weeral genormaliseerd moeten worden*

die backticks zijn een lelijke gewoonte van me =/

*
edit

toegevoegd+genormaliseerd
Eduard schreef op 05.04.2008 15:36
is niet echt logisch om eerst te normaliseren en daarna telkens nieuwe attributen te ontdekken die weeral genormaliseerd moeten worden
Dan ben je blijkbaar nog niet klaar met normaliseren. Wanneer later blijkt dat je nog iets moet toevoegen, heb je blijkbaar een fout gemaakt (iets over het hoofd gezien) of zijn de eisen veranderd.
volledig met je eens, ik wou gewoon even 100% zeker zijn over die ratio en verder doorgaan met het analyzeren van volgende informatie (om die dan samen met de rest in 1 keer te normaliseren)

Reageren