Als er is een kans dat je er twee krijgt met dezelfde datum, heb je waarschijnlijk nodig:
SELECT balance FROM my_table ORDER BY date_added DESC,id DESC LIMIT 1;
(let op de 'aflopende' clausule op beide velden).
U moet echter rekening houden met wat u wilt dat er gebeurt wanneer iemand een aanpassingsinvoer van 2 februari toevoegt met de datum 31 januari om ervoor te zorgen dat de maand januari compleet is. Het zal een ID hebben die groter is dan die gemaakt op 1 februari.
Over het algemeen werken boekhoudsystemen gewoon op de datum. Misschien als je ons zou kunnen vertellen waarom de volgorde is belangrijk, we kunnen andere suggesties doen.
Als reactie op je opmerking:
Ik zou wat advies willen geven - dit is alles wat ik meteen kon bedenken, ik spuug meestal veel meer "advies" uit met nog minder aanmoediging :-) De eerste twee, meer databasegerelateerd dan boekhoudgerelateerd, zijn:
Doe eerst alles in de derde normaalvorm en keert alleen terug als en wanneer je prestatieproblemen hebt. Dit bespaart u veel angst met dubbele gegevens die uit de pas kunnen lopen. Zelfs als je teruggaat, gebruik triggers en andere DBMS-mogelijkheden om ervoor te zorgen dat gegevens niet uit de pas lopen.
Als u bijvoorbeeld uw zoekopdrachten op een achternaamkolom wilt versnellen, kunt u een bovennaam_achternaamkolom maken (geïndexeerd) en die vervolgens gebruiken om records te vinden die overeenkomen met uw zoekterm in hoofdletters. Dit zal bijna altijd sneller zijn dan de functie per rij upper(last_name) . U kunt een trigger voor invoegen/bijwerken gebruiken om ervoor te zorgen dat de upper_last_name altijd correct is ingesteld en dit brengt alleen kosten met zich mee wanneer de naam verandert, niet elke keer dat u zoekt.
Ten tweede, dupliceer geen gegevens, zelfs niet tussen tabellen (zoals uw huidige schema), tenzij u dezelfde trigger-type trucs kunt gebruiken om te garanderen dat de gegevens niet uit de pas lopen. Wat doet uw klant als u hem een factuur stuurt waarvan het eindsaldo niet overeenkomt met het beginsaldo plus aankopen? Dat zal uw bedrijf er niet erg professioneel uit laten zien :-)
Ten derde (en dit is meer boekhoudgerelateerd), hoeft u zich over het algemeen geen zorgen te maken over het aantal transacties bij het direct berekenen van saldi. Dat komt omdat boekhoudsystemen meestal een doorrolfunctie hebben aan het einde van het jaar die de beginsaldi opnieuw instelt.
U hoeft dus meestal nooit meer dan een jaar aan gegevens tegelijk te verwerken, wat niet zo belastend is, tenzij u de Amerikaanse overheid of Microsoft bent.