Gå til innhold

gjestebok på php


Anbefalte innlegg

Videoannonse
Annonse

AUTO_INCREMENT betyr at man begynner på 1 og teller oppover. Hver gang man legger inn noe i databasen øker nummeret med 1. Brukes vanligvis til brukerid eller lignende. Du må altså fjerne AUTO_INCREMENT fra alle feltene... Også kan du legge det inn i "nummer" feltet.

Lenke til kommentar

Bruk VARCHAR(255) for navn og url.

Utdyp den påstanden.

 

Jeg mener at med mindre applikasjonen på en eller annen måte krever en begrensning på URLs og navn brukere skriver inn, så ser jeg ingen grunn til å begrense dette i database-laget. Argumentet med at 255 tegn sikkert er nok holder rett og slett ikke mål. En URL kan være mye lenger enn 255 tegn.

Endret av Jonas
Lenke til kommentar

Bruk VARCHAR(255) for navn og url.

Utdyp den påstanden.

 

Jeg mener at med mindre applikasjonen på en eller annen måte krever en begrensning på URLs og navn brukere skriver inn, så ser jeg ingen grunn til å begrense dette i database-laget. Argumentet med at 255 tegn sikkert er nok holder rett og slett ikke mål. En URL kan være mye lenger enn 255 tegn.

 

Hiv på med Longtext så er du sikker :p

Lenke til kommentar

Bruk VARCHAR(255) for navn og url.

Utdyp den påstanden.

 

Jeg mener at med mindre applikasjonen på en eller annen måte krever en begrensning på URLs og navn brukere skriver inn, så ser jeg ingen grunn til å begrense dette i database-laget. Argumentet med at 255 tegn sikkert er nok holder rett og slett ikke mål. En URL kan være mye lenger enn 255 tegn.

På hvilken måte holder det ikke mål? 255 tegn er svært mye for et navn og en URL. I hvilken sammenheng mener du det er nødvendig å skrive inn et navn eller en URL som er lengre enn 255 tegn? Hva mener du burde være maksimal lengde i stedet?

Lenke til kommentar

Hvorfor kan man ikke argumentere med at «det sikkert er nok»? For det ikke er sikkert! Jeg har sett nok at dustete URLs der ute, det finnes plenty som overgår 255 tegn. Jeg mener at man ikke bør begrense det i det hele tatt, i den grad det er mulig. Det finnes selvfølgelig teoretiske grenser som f.eks. de som kommer av det begrensede adresseområdet vi har, men så lenge vi har med dagens datamaskiner å gjøre, så kommer vi desverre ikke unna dem på noen enkel og praktisk måte.

Lenke til kommentar

Nå er dette riktig nok et forferdelig dårlig eksempel, ettersom det er svært lite sannsynlig at noen som helst ville kommet over denne linken, men den viser at det ikke er noe i veien for at en URL kan overgå en begrensning på 255 tegn.

 

http://v8.lscache2.c.youtube.com/videoplayback?ip=0.0.0.0&sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Calgorithm%2Cburst%2Cfactor%2Coc%3AU0dYRlNUUF9FSkNNOF9LTlRB&fexp=905602&algorithm=throttle-factor&itag=5&ipbits=0&burst=40&sver=3&expire=1291392000&key=yt1&signature=3224C19695DD030A54F99BACDAC41341033EFD7E.C472F3E533B0A44144A39A8268249F2DE509D15F&factor=1.25&id=c23f86ab2bfa8fa6

Endret av Jonas
Lenke til kommentar

Ja, jeg veit nok at URLer kan være lengre enn 255 tegn. Det er ikke poenget mitt. Poenget er at det ikke er ensbetydende med at noen ønsker å lime eller skrive den inn som URL (underforstått hjemmeside) i en gjestebok. Dessuten, det finnes begrensninger i nettleserne. Er det da noe poeng å f.eks. tillate mer enn 2048 tegn i en URL når IE ikke tillater dette?

Lenke til kommentar
Er det da noe poeng å f.eks. tillate mer enn 2048 tegn i en URL når IE ikke tillater dette?

Hvorvidt man vil lage en side som med stor sikkerhet kan sies å være kombatibel med IE får være opp til hver enkelt aktør på internett. Men ja, det er et poeng med å tillate mer enn 2048 tegn, nemlig å tillate alle URLs. Uansett, dette går litt utenfor det i hvert fall jeg ville diskutere.

 

Jeg mener rett og slett at med mindre man har en god grunn til å gjøre noe, så burde man ikke gjøre det. Det gjelder både introdusere lengdebegrensninger og f.eks. å begrense mulige tegn en tillater å bruke i brukernavn. I alle mine applikasjoner tillater jeg all mulig input og gjør hensiktsmessig escaping avhengig av hva slags medium jeg outputer til. Dette er i motsetning til å f.eks. gå over med htmlentities() ved innsetting i databasen, fordi det er ikke implisert at dataen utelukkende skal vises som HTML etterpå.

Lenke til kommentar

Er det best med eller uten SQL

 

Hvis du er ute etter hastighet, uten SQL.

SQL er noe treigere tror jeg, spesielt hvis du har mange besøkende og aktive på en gang. Men det har du neppe, så samme hva du bruker egentlig uten å merke noen forskjell på hastigheten/ytelsen siden laster på.

 

Selvfølgelig kan du også optimisere mysql sine konfigurasjoner.

Lenke til kommentar

Å benytte en SQL-database er nok ubestridt bedre enn flatfiler. Ja, man må lære seg SQL, men det må man nesten lære seg før eller siden når man driver med PHP og web. Dessuten er det vel ytterst få som driver med PHP som faktisk tenker på samtidighetsproblemer/«concurrency», og dermed helt glemmer å låse filen(e) ved skriving. I lengden skal det medføre litt krasj mellom to eller flere forespørsler. I tillegg er det veldig mye jobb å få den samme fleksibiliteten som man har med en SQL-database. I SQL kan man glatt sortere alle innlegg etter hvilke kriterier man måtte ønske, mens med flatfiler må man gjøre hele arbeidet med å sortere selv.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...