Nå skal du få et tips her. Tenk mer generelt: La oss si du har forskjellige typer innhold; artikler, guider, nyheter, pressemeldinger og så videre.

Alle disse har fellestrekk; f.eks. har alle en tittel, selve teksten og en ingress. Hvorfor ikke opprette en egen tabell for all slags innhold? La oss kalle alle sammen "innhold".

Du kan så lage en egen tabell for innhold. Her kan du gi innholdet en ID med datatype integer, et felt for tittel, f.eks. varchar og ingress med varchar. I tillegg er hovedteksten lagret i et felt av typen text.

Videre kan du lage en egen tabell for hva slags type innhold man har. La oss kalle det innholdstype. Her kan du ha en innholdstype for hver rad i tabellen, f.eks artikkel, guide og pressemelding. I tillegg har hver innholdstype en ID. F.eks. 1 for artikkel, 2 for guide og 3 for pressemelding.

Kanskje du også vil opprettte kategorier i tillegg til de forskjellige innholdstypene, f.eks. produkter, tjenester el.l. Også her lagrer du dem i en egen tabell med ID og navn på kategorien. 1 for produkter og 2 for tjenester.

Til slutt bør du opprette en egen tabell for å knytte de forskjellige IDene sammen. Denne kan inneholde ett felt for hver ID i de andre tabellene. I dette tilfellet ID for innhold, ID for innholdstype og ID for kategori.

Lagring av innhold i database

Du kan så lage et eget backend på websiden din. Her kan du legge inn artikler, pressemeldinger og guider direkte inn i databasen. F.eks. ved hjelp av et input slik som her i forumet. Du lagrer HTML-markup osv i databasen.

La oss si du skal skrive din første bit med innhold (ID 1 for innholdet) som er en pressemelding (ID 3) om et nytt produkt (ID 1). Du må da lagre IDene i tabellen for IDer, og tittel, ingress og selve innholdet i tabellen for innholdet.

I tabellen for innhold har du altså lagret alt som har direkte med innholdet å gjøre, mens innholdstypen og kategorien knyttes til innholdet ved hjelp av tabellen med IDer.

Visning av innhold fra database

Siden menyer, logo og så videre som oftest er statiske, dvs like på alle sider, faller det seg naturlig å lage en mal. I malen plasserer man alle statiske elementer ferdig.

Deretter henter man ut innholdet fra databasen basert på query stringen når man caller malen (går inn på siden), og printer deretter ut riktig innhold.

De sorte rutene: Her er et eksempel på databasestruktur du kan bruke i MySQL. Legg merke til at det er 4 tabeller, hver med sine felter i rødt.

Den grønne ruten forestiller hva som skal skje når en bruker går inn på en gitt adresse. Query string som sendes til server er skrevet i rødt.

Legg merke til at den siste tabellen kun inneholder IDer, disse knytter de tre foregående tabellene sammen.

I databasestrukturen ovenfor må du joine tabeller i SQL-spørringen din for å hente ut informasjon fra tabellene med innhold og navnet på kategorien.

Dette kan være nyttig f.eks. hvis du vil skrive ut hvilken kategori innholdet er katalogisert under. I tillegg kan du hente ut hvilken type innhold det er snakk om.

Ser du skrev innlegget over mens jeg skrev. Men sier det likevel: Du har én tabell for alt innhold (uavhengig av hva slags innhold det er), så har du én tabell for alle kategorier, én tabell for alle innholdstyper og så linker du dem sammen ved hjelp av IDen til de forskjellige "elementene" i en siste tabell. Du kan si den siste tabellen brukes til å knytte dataene sammen ved hjelp av nøkler (IDer).

Forklarer litt til angående dette med IDer.

Hvis du har tilgang til en ID, så har du indirekte tilgang til alt som er lagret på den IDen, ikke sant? Eksempel: Du husker IDen på en artikkel, derfor kan du enkelt finne hvor artikkelen er lagret i databasen.

Hvis du ser på tabellen med alle IDene, så ser du at du ved å vite 1 ID har tilgang til alle andre IDer som har tilknytning til den - dermed har du indirekte tilgang til all informasjon lagret bak de andre IDene også.

Skjønner at dette kan være vanskelig å forstå, men du kan se slik på det:

Du har to kister, en stor og en liten. På den lille er det 1 hengelås, på den store er det mange. Du har kun 1 nøkkel. Hvis du låser opp den lille kista, så har du tilgang til alle de andre nøklene og får se innholdet i den store kista.

Her korresponderer den lille kista til tabellen som inneholder alle IDene.

Da er det bare å ta på seg øyelappen, skrike kaptein sortebill og jakte på IDer og innhold, haha *overtrøtt* og har sett for meget på tangerudbakken, hehe.

Ja, jeg så at du hadde skrevet hvorfor du likte andre typer IDer, hehe. I et stort logistikksystem kan jeg se nytteverdien av slike systemer, men for å dele inn innhold, kategorier og så videre vil praksisen jeg outliner være best. Det er denne som er normal å bruke, så å finne opp egne og komplekse systemer er lite nødvendig.

Men for all del - man lærer jo av å eksperimentere, så hvorfor ikke :)

Jepp, alt innhold kan gå i en tabell. Det er jo i bunn og grunn samme type data som skal lagres, så å skille ut i egne tabeller er jo unødvendig.

Dette kan du jo velge selv. F.eks. kan du gi din egen bruker sysoprettighet, og dermed tilgang til egne options som andre ikke vil se.

Du kan også legge inn data direkte fra phpMyAdmin hvis du ikke gidder å kode backendet. Er jo mye jobb med backend, for husk at du skal ha mulighet til å redigere ting også. Da må du hente ut ting og så videre, oppdatere de riktige feltene og masse annet snask.

Denne jobben gjør man jo rimelig enkelt i phpMyAdmin allerede. Ikke like fancy, men det er kanskje bare deg som ser det uansett?

Hviken ID du vil basere deg på kommer ann på hva du vil vise. Som jeg illustrerte ovenfor trenger du kun 1 nøkkel for å få tilgang til alle nøklene.

Si du vil vise en liste over artikler: Du vet hvilken ID innholdstypen "artikkel" har, og da kan du hente ut alle artikler som er knyttet til denne innholdstypen ved hjelp av en SQL-join. Dette er fordi du har assosiert alle innholdsIDer som er artikler med IDen til innholdstypen "artikkel", skjønner?

Tenk logisk: Hvis du skal vise en spesiell rad med innhold (f.eks én artikkel), så bruker du innholds ID, skal du vise en liste med artikler så bruker du innholdstype ID. Skal du vise alt innhold som har en relasjon til en spesiell kategori så bruker du kategori ID.

Skal se om jeg finner tid til å lage noen videoer om MySQL de kommende dagene.

Som jeg har forstått det, så er det summary_ID'en jeg skal benytte meg av når jeg spørre etter artikkelen. sant?

Jeg har aldri sagt at det er nødvendig å ha en egen ID for hver rad i denne tabellen.

Ja, du kan jo lage et eget felt i brukertabellen din som heter user_type el.l. Her kan du sette at din bruker er "sysop", mens andre er "users".

Videre; når man logger inn kan du sette en ekstra SESSION-variabel, f.eks. $_SESSION['user_type']. Deretter kan du bruke en if-statement for å kun vise innloggede brukere hvor $_SESSION['user_type'] er "sysop" skjemaet for innlegging av data, mens andre kan få beskjed om at de ikke har tilgang til websiden. :)

Nå overkompliserer du igjen. Tenk gjennom hvordan løsningen skal fungere i praksis. Når jeg skal programmere noe så tenker jeg trinn-for-trinn.

La oss si du skulle programmere en robot som skulle ta oppvasken for deg. Hvordan ville du gå frem? Jeg ville sagt at roboten skulle:

1. Sette i proppen
2. Åpne vannet i en spesifisert temperatur
3. Lukke vannet etter et visst nivå
4. Vaske opp
5. Skylle med kaldt vann
6. Tørke
7. Dra ut proppen

Deretter hadde jeg gått inn i finurlighetene, dvs; hvilken arm som skulle gjøre hva, hvordan hvert ledd i armen skulle fungere og så videre.

Med andre ord: Ha en outline, så løse hvert problem fra 1-7.

I ditt tilfelle må du gi deg selv rollen sysop i databasen. Dette kan du gjøre i phpMyAdmin. Videre kan du definere feltet slik at alle blir satt som "user" ved default. F.eks. når de oppretter brukeren for første gang.

Videre kan du lage funksjonalitet som kan skru av og på hvilken brukerrolle en gitt bruker skal ha i hans eller hennes profil, eller du kan lage en oversikt over brukere og sette rollene på dem der, valget er ditt.

Hovedpoenget er at du setter brukerrollen i en session, slik at du senere kan kode script som sjekker denne;

Ovenfor kunne du satt inn et skjema som ga en viss bruker en rolle osv, og deretter oppdatert databasen basert på hva en sysop valgte fra den listen.

Jepp, nå er du på riktig vei. :)

Helt enig med deg i at et tallbasert system er bedre, det er slik jeg også pleier å gjøre det. I tillegg lager jeg en funksjon som returnerer hvilken gruppe man tilhører, ved å bruke tallet som argument i funksjonen. Fint at du ser slike ting på egenhånd, det vitner om at du ikke bare plukker bær, hehe.

Du kan sende en "Permission denied" header til de som ikke er innlogget, men dette må du i tilfellet gjøre før du printer ut beskjed. Men det vet du.

Når det gjelder scriptet du beskriver her, så vet jeg ikke helt. Ser jo ikke hvordan scriptet ser ut basert på de opplysningene du kommer med. Jeg antar at du skjønner at absolutt alt som skal på den siden må mellom brakettene etter du har sjekket om SESSION er satt, type:

if(blabla) { alt på websiden} else { ingen tilgang }

Hvis du får errorer da, så ville jeg i tilfellet ha sett over queryene jeg sendte altså. Ingenting som står inne i en if-clause skal kjøres såfremt det som validerer er false.

Bra du fikk det til. Jeg ville ikke stolt på innholdet i arrayen $_SERVER['HTTP_REFERER'], den er nemlig enkel å modifisere. Videre kan folk gå rett inn på siden, og da er ikke denne satt (siden de ikke klikket en link for å komme dit).

Er det ikke bedre å vise en error da? Uansett. Print ut innholdet av $_SERVER['HTTP_REFERER'] og se hva du finner når du klikker deg dit med gale innstillinger. Da ser du fort hva som er leif.

Men denne tråden er langt ute på viddene nå. Den handlet primært om å lagre innhold i MySQL, mens den nå omhandler hvordan man lager et backend og alle finurlighetene som hører med på et nettsted.

Her spør du ikke lenger hvordan man lagrer informasjon i databasen, men om hvordan man skal bruke join i SQL. Lag en ny tråd på dette.

Hvis du allerede har lagret for- og etternavn i hvert sitt felt, hvorfor ha dem i et eget felt? Det blir jo dobbel lagring av samme data, noe som er unødvendig i en relasjonsdatabase. Dette går inn under såkalt normalisering.

Uansett, for å hente ut fra en database og sette inn i en annen så er det jo bare å kjøre en spørring på navnene som ligger der, kombinere variablene som utgjør fornavn og etternav og så kjøre en ny SQL-query der du lagrer dem igjen.

Enig.

Nå bytter ikke folk navn så ofte, men grunnen til at man normaliserer er fordi man da kan være mer sikker på riktigheten av data. Ta for eksempel dette med adresser. Om man har et system som lagrer adressene til brukerne, så vil man kun lagre dette på ett sted. Grunnen er selvfølgelig at man skal kunne endre adressen på ett sted, så trer virkningene i kraft alle steder, og man kan være sikker på at det er riktig.

Men det er også tilfeller hvor vi ikke ønsker å normalisere. Se på dette med adresser igjen. La oss si du har et ordresystem. Her står gjerne leveringsadressen på diverse fakturaer. Hvis systemet lager fakturaene on the fly med data fra databasen, så skal selvsagt ikke gamle adresser fjernes fra disse selvom brukeren oppdaterer adressen sin.

I et sånt tilfelle bør man altså lagre adressen for hver faktura. Men også her kan man normalisere.

For eksempel kan man gi adresser IDer. Gjør man det så vil kun én adresse lagres én gang i en egen tabell.

Det er med andre ord mange måter å gjøre ting på.