Man bruker stort sett én database per system. Dvs: Hvis du har to websider, så opererer gjerne hver webside i sin database. Et eksempel er hvis du har nettbutikk og forum, da bruker man gjerne én database til hver implementasjon.

For å skille informasjon (brukerdata, artikler, innstillinger) på en webside, bruker man gjerne tabeller.

Kommentarer, artikler og så videre lagres gjerne i databasen, ja. Videre er det noe som heter normalisering, det går ut på at man ikke skal lagre samme data mer enn én gang. Ta dette eksemplet:

Man har en bruker med brukerID 1, i databasen har denne brukeren registrert brukernavn, vanlig navn og så videre. Hvis brukeren skriver en kommentar, så trenger man ikke lagre brukernavnet én gang til for hver kommentar, men man tar heller utgangspunkt i brukerIDen.

Det vil si: En kommentar lagres med brukerIDen til kommentatoren, videre kan man bruke SQL joins for å hente ut data fra to (eller flere) tabeller i samme query, f.eks. brukernavn, hjemmesiden til brukeren, link til profilen til brukeren og selve kommentaren.

Tips: Når du skal opprette databasene - ikke overkompliser databasestrukturen. Totalt unødvendig å skille logiske data fra hverandre i forskjellige tables. I brukertabellen putter du alt som har med brukeren å gjøre, fra navn til adresse og kanskje også preferanser vedkommende har satt på websiden din.

Ja, man må ha én referanse å forholde seg til, og man kan bruke linking tables som utelukkende inneholder referansenøkler (IDer).

Eksempel: Man har en webside hvor brukere kan skrive artikler, hvert medlem har sin ID og hver artikkel har sin ID. Man lagrer naturligvis medlemsinfo i én tabell, mens artikkelen og artikkelID går i en annen.

Nå kan man opprette en tredje tabell som inneholder to felter, ett for brukerID og ett for artikkelID. Dermed har man linket hver artikkel til hver bruker, uten å forsøple artikkel-tabellen med et felt for brukerIDer.

Det samme kan man gjøre med kommentarer. En tabell for brukeren, en tabell for artikler og en tabell for kommentarer. I tillegg til en linketabell som holder brukerID, artikkelID og kommentarID. På den måten har man knyttet hver kommentar til en artikkel og en bruker. Man kan så hente ut opplysninger fra både artikkel- bruker- og kommentartabellen i én og samme query/spørring.

Login og brukerinfo kan jo være i samme tabell, da all informasjonen som angår en bruker inngår logisk i brukertabellen (de gjelder jo brukeren). Det er ikke nødvendig å skille ut ting som epost, adresse, passord, telefonnummer og så videre i andre tabeller. De lagrer man sammen med brukerID, slik at man kan bruke brukerID for å hente ut denne informasjonen om den trengs.

Det er først når man ønsker å knytte andre elementer til brukeren at det er interessant å lage flere tabeller.

Tenk på artiklene igjen:

1. Tabell med brukerdata og bruker-ID
2. Tabell med artikkel og artikkel-ID
3. Tabell som knytter artikkel-ID til bruker-ID

Tabell nummer 3 har bare to felter, ett for brukerID og ett for artikkelID. Deretter kan man begynne å joine tables når man skriver spørringer.

Jeg vet ikke ellers hvordan jeg skal forklare det, det blir som at man linker ting sammen med IDer. (Staten bruker personnummerne våre på denne måten. Det er din ID i samfunnet, og all informasjon om deg, bøter, selvangivelser og you name it linkes opp mot denne).

Ja, bare legg alt sammen i samme tabell.

Det vanligste når man lar brukerne sette sine egne brukernavn er å først kjøre en spørring på det brukernavnet, og hvis det finnes så sier man ifra at det er opptatt, hvis det er ledig så lar man brukeren registrere seg. Ved å gjøre det på den måten så får de jo anledning til å sette et brukernavn som ikke er opptatt også.

(UNIQUE gir vel også en error dersom brukernavnet er opptatt, men jeg synes det er enklere å gjøre det med en spørring).

Det vanligste er at man setter IDen på hver tabell til primary key, og gjerne auto increment.

Ok. Angående passord: Du kan sette brukerID i en session og når vedkommende skifter passord, så endrer du passordet i databasen for den brukerIDen. Ville også kryptert passord, det gjør du ved å bruke funksjonen PASSWORD('passordet') i SQL-spørringen.

F.eks. "UPDATE users SET pass = PASSWORD('12345') WHERE userID = 1;"

Angående gjenta passord: Lag to inputs av type password. Kjør en IF i PHP som sjekker hvorvidt den første er lik den andre, Legg så inn det nye passordet hvis begge er like.

Hva mener du med å se det "live"?

Jeg skjønner hva du mener. Til det kan du bruke jQuery (eller JavaScript). På samme måte som du validerer i PHP kan du validere med jQuery. Du henter verdien av de to feltene, du sammenligner de to feltene, hvis samstemt så viser du OK (og aktiverer submitknappen), ved feil er submitknappen deaktivert, og beskjeden er "feil", el.l.

Du har jo en god del ønsker om slik interaktivitet på websiden din, så jeg skjønner ikke hvorfor du ikke bare begynner å lære deg litt jQuery. Du forstår jo både HTML, CSS og mye PHP - så da er jo jQuery ganske plankekjøring - i alle fall på dette nivået.

Det handler jo bare om å velge elementer (f.eks. en paragraf/avsnitt), hente eventuelle verdier i elementer og kjøre tester på dem, endre verdier o.l.

Angående PHP-eksemplet ditt, slik ville jeg gjort det.

Det er ikke så mye historie bak jQuery, da det ble lansert i 2006. Siden da har det blitt det mest brukte JavaScript biblioteket i verden. Du kan lese mer om jQuery på Wikipedia.

Ellers er det bare å sette seg ned og prøve seg frem egentlig. W3Schools har litt om jQuery, men personlig liker jeg best å bruke jQuery sine websider. Her er endel tutorialer i jQuery på deres side. De har også en utmerket wiki som jeg bruker mens jeg koder, nemlig "API Refrence", der kan man sjekke ut alle funksjoner, hva de gjør og de har rikelig med eksempler.

Blir nok litt om jQuery her på Hjemmeside etterhvert også, men først må jeg sette meg ned å få laget et par videoer til i de andre emnene. Det er jo mye triveligere på holde på i forumet enn å sitte å lage de videoene, hehe.