en til mange

I tabel 1 skal personid være primær nøgle
I tabel 2 bør du udvide med en primærnøgle (et
autonummereret felt er fint her), og gøre personid
til et index.

Jeg har lavet en kombineret primærnøgle på personID, dato og tid.
Er det ikke det smarteste?

/snedled

Nej, det tager for meget plads og tid. Du vil aldrig søge
efter den præcise kombination.

OK. Det kan godt være at det er det smarteste. Men selvom jeg tilføjer et logID her, har jeg stadig probs med at få det rigtige hentet.

 I virkeligheden ville jeg gerne kunne hente fx. de sidste 3 logs fra hver person, sådan at man kunne få listet:
| navn1 | dato, tid | dato, tid | dato, tid |
| navn2 | dato, tid | dato, tid | dato, tid |

Det jeg hidtil har gjort er at benytte php til at samle flere kald, men er i tvivl om det er det hurtigste....

 Den anden måde, som jeg egentlig spørger om her, har jeg tidligere brugt en MAX() til, men er det egentlig hurtigst?

...er måske lidt uklar?!


/snedled

Du bør forøvrigt kombinere dato og tid til ét felt af typen
DATETIME i MySql - så kan du nemmere håndtere at finde den nyeste
dato.

Du siger at du i en udskrift gerne vil have de 3 sidste datoer/tid
for hver person? Hmm, det kan man da ikke lave med én sql-sætning.
Kan man?

Tabellerne er gode nok, du skal bare joine dem i SQL

Select *
from person p,logged l
where p.personid = l.personid

de tre nyeste:

Select top 3 *
from person p,logged l
where p.personid = l.personid
order l.dato,l.tid

Ja, det er jo lidt det spørgsmålet er :-D
Men det kan godt være at det er hurtigere at klare det i PHP'en....

Jeg prøver bare at rykke lidt videre, da jeg aldrig har benyttet mange af de muligheder (jeg tror) mySQL har....

...for lang tid om at skrive :0)
Arnvig > Kan man joine disse 2 i sql? - Eller skal jeg gøre det i PHP'en?

Ja, du bør joine i MySql-en, men den eneste måde du kan
gøre det er så du får alle datoer for alle personer. Og
det er jo lidt usmart. Det er også usmart at tage personerne
én for én og så lave en SELECT med LIMIT 3.

Skal vi se om der kommer nogen med en god idé.

Men det er nemt nok at få den sidste datotid for hver
person i én forespørgsel, forudsat datotid er ét felt.

OK. - Nu har jeg selv fundet en løsning:
SELECT person.*, logged.*
FROM person, logged
WHERE person.personID = logged.personID
GROUP BY person.personID
ORDER BY logged.dato

Denne løser mit umiddelbare problem, og henter alle personerne sorteret efter deres sidste logon(dato).

mht. DATETIME, skal de kun sorteres efter dato, tiden er irrellevant i den forbindelse, det er derfor jeg har lavet den som 2 kolonner..

/snedled

Ellers kan du udvide din person med tre felter, som du så opdaterer
ved en ny dato.

update person set dato1=dato2, dato2=dato3, dato3='2003-02-04' where id=117

(sådan ca.) Så har du altid de tre sidste

Nå ja, og teste for om det er en allerede registreret dato er nem:

update person set dato1=dato2, dato2=dato3, dato3='2003-02-04' where id=117 and dato3<>'2003-02-04'

Det generaliserer ikke så nemt, den dag du hellere vil have de
sidste 4 datoer :)

Ja, det overvejer jeg også, men det bryder lidt med normaliseringsreglerne, ikke?

Jeg tror at jeg undlader de 2 andre datoer og nøjes med den sidste.

Erik, du siger at det kræver mere plads og tid at have en kombineret primærnøgle. Vil det sige at det generelt - rent effektivitetsmæssigt - er bedre at have én primærnøgle og så tjekke for dubletter i php'en?

/snedled

Hvis du skal checke for dubletter skal man overveje et index
på det der skal checkes for. Men du søger da ikke efter
dubletter på id,dato og tid?

Joh, det er nok ikke så kønt, mit forslag. Alternativet er
jo at have en tabel ved siden af, hvor du indsætter den nye
dato, og så sletter den ældste så der altid er 3. Det generaliserer
nemmere, men er knap så effektivt.

Jeg tjekker ikke på dubletter egentlig, men den samme person kan ikke være logget på samtidig, så den er ihvertfald unik, så tænkte jeg bare at spare en kolonne og lavede istedet de 3 kombinerede. Troede egentlig ikke at de var langtsomme....

Jeg tror at den smarteste måde at hente de tre på er ved at lave "joinet" i PHP'en. På den måde undgås nok alt for unødigt komplicerede løsninger....
- spørgsmålet er bare om det er væsentligt langtsommere på den måde (ved at det er den forkerte kategori til PHP-spørgsmål).

/snedled

Hvis du aldrig rydder op i dine data, vil din join, og dit
gennemløb af resultatet blive langsommere med tiden. Derfor
kan det jo godt være hurtigt nok i dag.

Ja det er rigtigt. - Men det kan vel løses ved løbende at rydde op, eller fx slette de ældste logons hver gang en person logger på?

Jeg tror jeg vil lukke sprøgsmålet igen.

Du skal ha' tak for hjælpen Erik. Jeg skal nok vende tilbage hvis jeg har nogle andre underlige problemer..... :-D

Hvis du vil have del i pointne, må du lige lave et svar....

/snedled

Ingen point tak (jeg skal ikke have mig et gratis PRO abonnement)

...hmmm...
Hvad skal jeg så gøre af pointene?

/snedled

Jeg er sådan set ligeglad :)

OK :-D