[sql] Uitsluitend 3 nieuwste postings

[Verwijderd]

Mijn database structuur:

code:

news_id  title  message   c_timestamp
1        ...    ...       2003-09-21 20:24:01
2        ...    ...       etc

Nu wil ik met een (My)SQL query uitsluitend de nieuwste 3 nieuwsberichten uitlezen...

Als ik gebruik maak van MAX(c_timestamp) krijg ik uitsluitend de allerlaatste, wat natuurlijk logisch is. Helaas kan ik niets bedenken om dit op te vangen...

[Kippenijzer]

Aflopende schikken op timestamp en dan aangeven dat je maar 3 elementen in je result wilt gewoon?

edit:
Ik zie MySql staan, dan is het : ORDER BY c_timestamp DESC LIMIT 3

[ Voor 30% gewijzigd door Kippenijzer op 21-09-2003 20:29 ]

[dArtagnan]

voer de volgende query uit:

SELECT news_id, title, message, c_timesamp
FROM news
ORDER BY c_timesamp DESC
LIMIT 0,3


uitleg:
ORDER BY
om aan te geven waarop er gesorteerd moet worden

DESC
achterstevoren ordenen

LIMIT
om het aantal post aan te geven. Het eerste getal is waar hij moet beginnen en het tweede getal is het aantal posts.

[ Voor 50% gewijzigd door dArtagnan op 21-09-2003 20:38 ]

[Verwijderd]

waarom niet gewoon sorteren op id?

SQL:

SELECT news_id, title, message, c_timestamp
FROM news
ORDER BY news_id DESC
LIMIT 0,3

[Verwijderd]

omdat je sql query's "moet" schrijven zoals je ze bedenkt. Het levert allebei dezelfde resultaten op, maar als je later nog eens terugleest, snap je sneller wat de bedoeling is wanneer je op c_timestamp hebt gesorteerd...

[whoami]

Verwijderd schreef op 21 September 2003 @ 20:41:
waarom niet gewoon sorteren op id?

SQL:

SELECT news_id, title, message, c_timestamp
FROM news
ORDER BY news_id DESC
LIMIT 0,3

Waarom wel? Wie zegt dat het hoogste id ook het laatste is? Normaal gezien wel, maar het is veiliger dat je sorteert op die timestamp. Het maakt de code ook duidelijker.

[djluc]

Als je een autoincrement gebruikt die je niet beinvloed met je code maakt het geen verschil. Ik vraag me af wat sneller sorteerd, dat zou dan nog weleens verschil kunnen maken, al moet dat verschil met indexes minimaal zijn. Dat kun je alleen maar weten door te testen.

[Macros]

Natuurlijk sorteerd het veel sneller op id omdat het primairy key is heeft het een index, dus sorteerd het sneller.

[bigtree]

Macros schreef op 21 september 2003 @ 23:07:
Natuurlijk sorteerd het veel sneller op id omdat het primairy key is heeft het een index, dus sorteerd het sneller.

Een primary key is 'gewoon' een UNIQUE INDEX.

A PRIMARY KEY is a unique KEY where all key columns must be defined as NOT NULL.

Kan me niet voorstellen dat de laatste drie records op basis van id ophalen sneller zou zijn dan de laatste drie records ophalen op basis van timestamp.

[dArtagnan]

bigtree schreef op 21 september 2003 @ 23:29:
[...]
Een primary key is 'gewoon' een UNIQUE INDEX.
[...]
Kan me niet voorstellen dat de laatste drie records op basis van id ophalen sneller zou zijn dan de laatste drie records ophalen op basis van timestamp.

Ik heb het even getest op een bestaande tabel uit mijn database. Een tabel kunstenaars waarin kunstenaars staan. Een keer gesorteerd op id en een keer op achternaam. Het sorteren op achternaam was 4x langzamer dan het sorteren op id.

test 1:

PHP:

for ($i=0; $i < 10000; $i++){

    $query = "
        SELECT kunstenaar_id
        FROM cms_kunstenaars
        ORDER BY kunstenaar_id DESC
        LIMIT 0,3 
            ";
    $result = mysql_query($query);
}

resultaat: 2.1718159914017 seconden (gem. van 5 pogingen)


test 2:

PHP:

for ($i=0; $i < 10000; $i++){

    $query = "
        SELECT kunstenaar_id
        FROM cms_kunstenaars
        ORDER BY kunstenaar_achternaam DESC
        LIMIT 0,3 
            ";
    $result = mysql_query($query);
}

resultaat: 7.9089620113373 seconden (gem. van 5 pogingen)

[whoami]

Macros schreef op 21 September 2003 @ 23:07:
Natuurlijk sorteerd het veel sneller op id omdat het primairy key is heeft het een index, dus sorteerd het sneller.

Niet noodzakelijk. Je kan ook een index leggen op datum natuurlijk.

Trouwens:
In SQL Server zou je bv een Primary key kunnen leggen op ID die een non-clustered index is, en zou je een clustered index kunnen leggen op datum.
De records in die tabel worden dan fysisch ook in volgorde van datum opgeslagen. Aangezien je dan de records opvraagt, en deze fysisch ook al gesorteerd zijn op datum, hoeft die sort helemaal niet meer uitgevoerd te worden, aangezien ze dat al zijn.

[whoami]

Koraalduivel schreef op 21 September 2003 @ 23:41:
[...]

Ik heb het even getest op een bestaande tabel uit mijn database. Een tabel kunstenaars waarin kunstenaars staan. Een keer gesorteerd op id en een keer op achternaam. Het sorteren op achternaam was 4x langzamer dan het sorteren op id.

Heb je ook wel een index liggen dan op 'achternaam'? Als je iets test, moet het wel een beetje vergelijkbaar zijn.

[Freee!!]

whoami schreef op 22 september 2003 @ 08:40:
[...]
Heb je ook wel een index liggen dan op 'achternaam'? Als je iets test, moet het wel een beetje vergelijkbaar zijn.

Precies mijn vraag. Great minds

[Creepy]

djluc schreef op 21 September 2003 @ 22:40:
Als je een autoincrement gebruikt die je niet beinvloed met je code maakt het geen verschil.

En toen heb je ontzettend veel verschillende id's gehad dat de autoincrement gaat loopen en hebben nieuw ingevoerde records ineens hele lage ID's (nee, de autoincrement verlaagt zichzelf niet automatisch als je records delete).

[whoami]

Creepy schreef op 22 September 2003 @ 08:51:
[...]

En toen heb je ontzettend veel verschillende id's gehad dat de autoincrement gaat loopen en hebben nieuw ingevoerde records ineens hele lage ID's (nee, de autoincrement verlaagt zichzelf niet automatisch als je records delete).

Ik denk dat het afhankelijk is van DBMS tot DBMS, maar ik denk niet dat een autoincrement veld gaat gaan 'loopen' als z'n limiet bereikt is.
Als dat het geval is, dan denk ik gewoon dat je geen records meer kunt toevoegen, aangezien je een overflow oid zult krijgen.
FF testen misschien?

[ Voor 3% gewijzigd door whoami op 22-09-2003 08:57 ]

[dArtagnan]

whoami schreef op 22 September 2003 @ 08:40:
[...]

Heb je ook wel een index liggen dan op 'achternaam'? Als je iets test, moet het wel een beetje vergelijkbaar zijn.

Er zat geen index op.

Maar ik heb het opnieuw geprobeerd met met een index. Nu wel op een andere tabel want het sorteren op een slechts cijfers gaat natuurlijk veel sneller dan het sorteren op alle karakteres. Het verschil tussen de twee tests is 12%. Maar als je dat bekijkt op een paar query's is het natuurlijk niks.

Test 1:

PHP:

for ($i=0; $i < 10000; $i++){

    $query = "
        SELECT foto_titel
        FROM cms_foto
        ORDER BY foto_id DESC
        LIMIT 0,3 
            ";
    $result = mysql_query($query);
}

Resultaat: 2.2800715923309 seconden (gem. 5 pogingen)
Tijd nodig per om een query uit te voeren: 0.000228 seconden

PHP:

for ($i=0; $i < 10000; $i++){

    $query = "
        SELECT foto_titel
        FROM cms_foto
        ORDER BY kunstenaar_id DESC
        LIMIT 0,3  
            ";
    $result = mysql_query($query);
}

Resultaat: 2.5503564119339 secondenseconden (gem. 5 pogingen)
Tijd nodig per om een query uit te voeren: 0.000255 seconden

[djluc]

Het hangt er echter vanaf of dit met een datum veld hetzelfde gabeurt. Ik kan me bijvoorbeeld voorstellen dat het sorteren van een datum wat langer zou kunnen duren, tenzij de index natuurlijk uit miliseconden vanaf een bepaalde datum bestaat. Zover gaat mijn kennis van de interne behandeling van db's echter niet.

[whoami]

djluc schreef op 22 september 2003 @ 17:52:
Het hangt er echter vanaf of dit met een datum veld hetzelfde gabeurt. Ik kan me bijvoorbeeld voorstellen dat het sorteren van een datum wat langer zou kunnen duren, tenzij de index natuurlijk uit miliseconden vanaf een bepaalde datum bestaat. Zover gaat mijn kennis van de interne behandeling van db's echter niet.

Waarom?
Een datum wordt gewoon als een getal opgeslagen. (2 getallen eigenlijk, 1 getal is de datum vanaf een startdatum, het 2de getal is de tijd)

[djluc]

Hoe die werd opgeslagen wist ik dus niet, als het inderdaad als een getal is dan maakt het qua snelheid niets uit zoals je ook in mijn post kunt lezen

[P_de_B]

whoami schreef op 22 september 2003 @ 08:56:
[...]


Ik denk dat het afhankelijk is van DBMS tot DBMS, maar ik denk niet dat een autoincrement veld gaat gaan 'loopen' als z'n limiet bereikt is.
Als dat het geval is, dan denk ik gewoon dat je geen records meer kunt toevoegen, aangezien je een overflow oid zult krijgen.
FF testen misschien?

Yep, overflow.

Nu wel op een andere tabel want het sorteren op een slechts cijfers gaat natuurlijk veel sneller dan het sorteren op alle karakteres

Niet per definitie

[dArtagnan]

Niet per definitie

Waarom niet? Het sorteren van iets dat maar 10 verschillende karakters kan bevatten zal toch veel sneller gaan dan iets dat bijvoorbeeld 30 verschillende karakters kan bevatten.

[ Voor 7% gewijzigd door dArtagnan op 22-09-2003 21:06 ]

[whoami]

Koraalduivel schreef op 22 September 2003 @ 21:06:
[...]

Waarom niet? Het sorteren van iets dat maar 10 verschillende karakters kan bevatten zal toch veel sneller gaan dan iets dat bijvoorbeeld 30 verschillende karakters kan bevatten.

Als je records fysisch al opgeslagen zijn in volgorde van dat veld, zal sorteren op dat veld zowiezo sneller gaan. Je hebt die records dan nl. al in volgorde.

[mocean]

Bij een nieuwssysteem kan ik me voortstellen dat de datum niet de datum van invoer is, maar de datum van het gebeurde. Dus de datumsortering hoeft dan niet gelijk te lopen met de ID's.

Bij bijvoorbeeld een agenda applicatie is dat duidelijker Dan voeg je steeds een datum toe van een event, de uiteindelijke volgorde van deze events heeft weinig te maken met de volgorde van de id's.

Maar ik zou dus sorteren op datum.