22. juni 2011 - 11:40Der er
14 kommentarer og 2 løsninger
Log tabel - uden at lægge server ned ?
Jeg har brug for at logge hvem som retter data, og hvornår.
Log: XiD (INT) hvad UiD (INT) hvem TiD (TIMESTAMP)
Så langt så godt.
Men nu vil jeg gerne oplyse brugeren om hvornår data blev rettet senest. - Altså ikke HELE loggen (førend hun aktivt beder om denne) - kun det allerseneste entry:
SELECT UiD,Time FROM Log WHERE XiD=? ORDER BY Time DESC LIMIT 1
Men hvad nu hvis data er blevet rettet en million gange ? Jeg frygter at den vil hente alle 1 million records op i ram, sortere pr. Time, og først SÅ limit'e til 1
Hvad ville være en mere effektiv måde at bede om dén seneste ?
rent logisk spørgsmål. Hvordan vil du have at systemet skal kunne fortælle hvad der er "den første" eller "max" uden at tage stilling til hvad den har i listen?
Umiddelbart er den eneste løsning at du kører et index på både XiD og TiD og på denne måde kan bruge en WHERE til at begrænse til kun én Xid, og så bruge MAX eller LIMIT til at vælge den korrekte. Og ja, er der én million poster tilbage efter WHERE, så skal den en million poster igennem...
Men at læse en million rækker i en enkelt tabel er vel heller ikke noget der lægger en stor farlig server ned. Hvis det var en join søgning der involverede en fem-seks tabeller hver med en million rækker ville det nok begynde at kunne mærkes.
Synes godt om
Slettet bruger
22. juni 2011 - 14:23#6
Der er kun de 3 felter i tabellen, og de indgår alle i primary key. - gør det nogen forskel ?
Eller er der en bedre måde at opnå resultatet på (intet er implementeret endnu) ?
Alternativ (jvf. #4) Jeg kunne gemme den seneste linje (UiD + TiD) direkte på XiD (foruden i Log). - så er de klar med det samme. Og jeg behøver kun at kigge i Log, når brugeren beder om mere..
helt enig med #5 - jeg har en logpost i mit drift system med over 200 millioner rækker. Der kan jeg da stadig slå data op (indexeret data dog) på millisekunder...
hvis de tre felter udgør en primærnøgle, så er de indexeret, og så kan du ikke komme nærmere end dette. Og ja, alternativet er at bruge en separat tabel til "sidste" post. Her ville jeg nok gøre brug af Stored Procedures, og så gennem dette sikre at hvis der gemmes, så gemmes der begge steder. Så kan du også lave en Stored Procedure der henter fra den korrekte tabel, alt efter om der bedes om 1 post eller mange poster. På denne måde skal dit "program" kun gemme og hente, og ikke have logik til at finde ud af om det er én eller mange og hvor der skal gemmes hvornår.
Jeg taenkte faktisk paa 2 felter i samme tabel ikke en separat tabel.
Synes godt om
Slettet bruger
22. juni 2011 - 18:44#14
#13 Det var også det jeg nåede frem til. XiD refererer til 4 forskellige typer data som kan gemmes - i hver deres tabel. - jeg tilføjer de 2 sidst-gemt-felter til hver af dem.
Og når jeg gemmer, overskriver jeg disse + opretter en record i log-tabellen.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
