Artikkeldatabase?

Jeg vil godt komme med nogle generelle retningslinier, som jeg anvender.

Hvorvidt artiklerne gemmes formateret, d.v.s. med HTML tags eller ej, afhænger af om du har standardiseret dine artikler (templates) eller om en bruger eks. kan tilføje en artikel med egen formatering, d.v.s. med brugervalgte tags.

Personligt anvender jeg altid templates (form), som brugerne kan indtaste en artikel i og gemmer således kun det \"rå\" indhold af artiklen. For at gemme liniskift og specialkarakterer, anvender jeg replace og HTMLencode funktionerne i ASP.

Billeder gemmer jeg altid udenfor databasen, og databasen indeholder således kun stien til billedet, og denne sætter jeg så i min <IMG> tag, når jeg viser artiklen. Du kan godt gemme billeder i en database, men det er efter min erfaring, noget af det værste at gøre performancemæssigt.

M.h.t. LIKE har du fuldstændig ret i, at det ikke er optimalt. Faktisk er det noget af det værste du kan gøre, da databasen oftest slet ikke kan anvende evt. indeks i en søgning. Derfor bør du undgå LIKE så vidt muligt.

Nu ved jeg ikke hvilken database du anvender, men hvis du eks. anvender SQL Server, bør du overveje \"full text indexing\" som alternativ, hvis du har behov for fritekssøgning á la LIKE.

Brugen af indeks skal altid afvejes mellem indtastning-, opdaterings- og søgningsfrekvens. Et indeks på de rigtige felter gør søgninger hurtigere, men sløver til gengæld opdateringer.

Et simpelt eksempel på at oprette et indeks:

CREATE INDEX artikler_efter_forfatter
  ON artikler (forfatterid)

Dette vil oprettet indekset \"artikler_efter_forfatter\" på tabellen \"artikler\" og feltet \"forfatterid\"

Håber ovenstående kan være til hjælp, selv om der ikke er meget konkret kode :-)

Hmm... Ja lidt.

Vil det sige at der i din db-tabel står: <br><b><i>.. osv? (altså du konvereterer newlines fra din form til <br> og tillader brugeren at bruge nogle få htmlkoder som <b><i> osv?!?

Jeg bruger MySQL.

Kan du komme med lidt mere info på det der indeksering? Lidt mere om hvad det er den gør? Gør den det automatiks? Og kan jeg gøre det med MySQL? Osv osv osv?

Tak for det ellers gode og fyldige svar :)

/NbG

Nej, tværtimod. Jeg gemmer næsten altid blot den rå tekst, med linieskift som vbCrLf (chr(13) + chr(10)). Så konverterer jeg dette til <BR> når jeg viser artiklen.

Du kan sagtens bruge indeks på MySQL. Syntaksen er næsten identisk med SQL Server, og er 100% identisk på et simpelt indeks. Du vil således kunne bruge eksemplet ovenfor på MySQL også.

Når du først har oprettet et indeks, vedligeholder det sig selv automatisk. D.v.s. at alle ændringer i tabellen på de indekserede felter aut. opdateret i indekset.

Et indeks kan bedst sammenlignes med indholdsfortegnelsen eller stikordsregistret i en bog; det er væsentlig hurtigere at finde et bestemt emne i en bog ved brug af eks. indholdsfortegnelsen, end at bladre hele bogen igennem og lede efter emnet.

Lad os antage at du eks. har tabellen artikler med felterne artikelid, forfatterid, dato, indhold og vil vise alle artikler af en bestemt forfatter med flg. SQL statement:

SELECT * FROM artikler WHERE forfatterid = 1

Så vil denne select foregå væsentligt hurtigere med nedenstående indeks end uden.

CREATE INDEX artikler_efter_forfatter
  ON artikler (forfatterid)


P.S. Du skal have en tabel med en vis mængde data, før du kan se en mærkbar forskel i dit udtræk. Men selv med få poster i tabellen, VIL der være en forskel i de systemresourcer (processor og memory) der anvendes til udtrækket.

Lidt mere om indeks...

Du bør altid oprette indeks på flg. felter:

1. Primær nøgler
2. Fremmed nøgler
3. Felter der ofte bruges i WHERE clausen

Lad os antage at du eks. har tabellen artikler med felterne artikelid, forfatterid, dato, indhold, med artikelid som primær nøgle

Og derudover tabellen forfattere med felterne forfatterid, navn

Din oftest anvendte SELECT er:

SELECT * FROM artikler WHERE dato > [en dato]

Så bør du lave disse indeks\'er

artikler: artikelid, forfatterid, dato (primær, fremmed, og ofte anvendt søge felt)
forfattere: forfatterid (primær)

Er det ligemeget om forfatterid\'et er et tal? Må det godt bare være: \"Hans Hansen\"?
Mange steder ser man folk bruger kategori_id=1 istedet for kategori_id=pornosites! Spiller det nogle roller, det er vel en index, sålænge der ikke bliver søgt med LIKE el. lign?

Gemmer db\'en så hele tiden selv en lille liste over alle forfattere? Altså lidt ligesom hvis man lavede en hel masse temp_tabeller som hver indeholdt alle de artikler forfatter 1 har skrevet, og alle de artikler forfatter to har skrevet osv... ???

Hvis nu forfatterid\'et skal stå som nummer, laver man så en hel tabel kun til at slå op hvad forfatteren hedder, eller er det fordi man regner med at forfatteren er medlem af et brugerskab, og den refererer så til brugeren med id\'et 1 (eks.)?

Man prøver vel altid på at kun skrive tingene en gang, og så bare kæde videre på det?

Hvad nu hvis man laver et index på et text-felt? Altså jeg vil gerne kunne fritekstsøge? Kan den så indekse alle ord i sådan et felt???

:)

/NbG (som godt ved det er mange q\'s at få kastet i hovedet)

Jeg kan kun lave :

Change Drop Primary Index Unique
-men der er ingen fremmed?

Hvad gør nøglerne?

/NbG

Nu er du inde på noget af det mest fundamentale i design af relationelle databaser; normalisering. Dette er et emne der er skrevet ufatteligt mange bøger om, og det er nok lidt for vidtgående til at dække det her.

Men for at besvare dine spørgsmål, ja det er lige meget om det er tekst eller tal. Men god skik er at anvende den mindst mulige datatype, som samtidig er stor nok til at indeholde poster nok - et lidt kryptisk svar :-)

Det mest normale med eksemplet artikler/forfattere vil være at have det normaliseret til 2 tabeller, hvor relationen mellem dem repræsenteres af en aut. tæller; det kaldes eks. autonummer og identity felter. Du vil således normalt ikke i begge tabeller have forfatteren repræsenteret som eks. \"Hans Hansen\", da dette kræver mere plads end at tilføje et heltals (integer) felt, hvor Hans er repræsenteret som 1. Du kan jo regne lidt på det, hvis vi nu leger at Hans har 100 artikler i databasen. Dette skal enten gemmes som 100 x \"Hans Hansen\" eller 100 x 1. Og hvad nu hvis Hans gifter sig eller af andre årsager ændrer navn til eks. \"Hans Pedersen\". Hvis du bruger en tæller som id på ham, skal du kun ændre navnet ét sted, nemlig navne feltet i forfattere. I det andet tilfælde vil du skulle rette det i alle de poster i artikler tabellen hvor Hans er forfatter, ellers vil du miste din relation.

Et lidt simplificeret eksemplet, men jeg tror du forstår pointen.

Du kan godt lave et indeks på et tekstfelt, men afhængig af databasen, vil eller vil den ikke kunne bruge indekset i eks. en LIKE %Hans% (i de fleste tilfælde er det ikke, og så er dit indeks spildt).

En fremmed nøgle, eller \"foreign key constraint\" anvendes primært til at sikre integretit i din database, således at du ikke kan have en post i én tabel, uden at have den påkrævede post i en relateret tabel. Fremmed nøgler er en af svaghederne i MySQL, og det er så vidt jeg husker ikke ordentligt implementeret endnu.

Men en fremmed nøgle bruges også til at beskrive relationer i et logisk database design. Du kan derfor ikke \"oprette\" en fremmed nøgle. En fremmed nøgle er et felt i en tabel, som er primær nøgle i en anden tabel.

Nå ok.
Nu har jeg alle mine arikler i én database. Jeg er den eneste der skriver, så forfatteren er altid mig! Jeg lister dem efter mit id (som er unikt og auto_increment), dvs uden WHERE men blor med ORDER BY. Skal jeg så have index på id? Eller er det overhovedet nødvendigt?


Vil det sige at hvis jeg kun har en tabel, der ikke \"snakker\" med andre, skal jeg ikke bruge primær? (så er det bare lidt underligt at den har den option i phpMyAdmin, hvis MySQL slet ikke kan bruge det)

MySQL kan sagtens bruge primær nøgler, og det bør der altid være på en tabel. Men da du kun har én tabel, har du ingen fremmed nøgler. Den er med i phpMyadmin, fordi primær nøgler er en fundamental del af databaser, men du kan godt VÆLGE ikke at bruge det.

Indeks er meget anvendeligt ved en ORDER BY, det er ikke kun i WHERE clausen. Så du bør lave et indeks på det/de felt/er du sorterer på.

Umiddelbart kunne det godt lyde som om MySQL er lidt overkill at anvende som database til din anvendelse, forstået på den måde at jeg får indtryk af, at du ikke har det helt store indblik i databaser (med fare for at fornærme dig). Med mindre du ønsker at uddybe din database viden, skulle du måske bare lade være med at bekymre dig om fremmednøgler, indeks o.s.v. hvis du kun skal bruge den ene tabel ?

Det eneste jeg ønsker at uddybe min database viden. For med 4 artikler i en database kan jeg nå at søge 1000 gange LIKE på alle felter før nogen ville opdage det :)
Så det er ikke fordi det går for langsomt eller noget, det er kun for at blive bedre!

Kan du evt. forklare hvad den rent praktisk gør ved sådan en index? på forfatter og på indhold (f.eks)


citat: \"Umiddelbart kunne det godt lyde som om MySQL er lidt overkill at anvende som database...\"
Betyder det at der ville være en bedre database at bruge istedet for? Eller var det bare et for at få mig vippet af?

/NbG

Jeg har skam ingen intentioner om at \"vippe dig af\". Det jeg mente var, at eks. MS Access måske ville være et bedre valg, forudsat at du har adgang til denne, at databasen vil få begrænset anvendelse (størrelse og anvendelse) og at det vigtigste for dig er at lære.

MySQL er en rimelig kompleks database, der på mange måder afviger fra ANSI SQL standarden og som umiddelbart måske ikke er den nemmeste database at lære ud fra. Omvendt kan du \"tage tyren ved hornene\", for hvis du mestrer MySQL, vil du forholdsvis nemt kunne skifte til Oracle, SQL Server o.s.v..

MySQL er en klart bedre database en Access, som kun er en desktop database, men den er noget nemmere at lære ud fra, primært fordi du kan gøre mange ting grafisk og så efterfølgende kigge på koden bagved.

Et indeks er i praktis blot én stor indholdsfortegnelse med en række \"pegepinde\" til de enkelte poster, som databasen slår op i. Jeg kan nok ikke forklare det nammere uden at det bliver alt for teknisk. Hvis du vil vide præcist hvordan det fungerer i praksis, vil jeg anbefale dig at købe en bog hvor emnet er dækket, da det er et emne der \"fylder meget\" i databasedesign.

Tak for det gode og lærerige svar tmceu!
Jeg lader lige spørgsmålet stå åbent lidt endnu, ihåb om at få andres meninger at høre.

/NbG

Davs.
Jeg kastede mig også i lag med mysql for ca 3 måneder siden, og arbejder godt med det den dag i dag.. Phpmyadmin er en god hjælpende hån til at styre databasen, men på download.com eller twocows.com kan du hente \"mysqlfront\" som ligner MS Acces .. men som er beregnet til Mysql .. det er utroligt let at benytte, og skal køres under windows..
Kig på det.

Iøvrigt en fed hjælp i har fået skabt her.. god debat.. eller hva man nu lige kalder det ;-)