MySQL tekstsider lagring ??

Tags:    database mysql tekst

Hejsa

Jeg sidder med tanker omkring et webprojekt der rummer tusindvis af tekstsider som skal ligge online, og være søgbare ..

Det vil jo blive en voldsom database, og har læst lidt rundt om forskellige læsningsmuligheder, bl.a. ved at lade dem ligge som filer, og lave en søgeindexdatabase over de forskellige ord på de givne tekstsider ..

Er der en optimal løsning her ??

Er det det smarteste at lave, og her tænker jeg både på databasestørelse og belastning, samt hastighed, både ved alm. brug og ved søgning ??

Jeg tænker hvis det laves på den måde, og man evt. laver to søgemuligheder, en på tags, og så en på regulære ord i selve teksten, så har man jo altid et valg, og vil ikke altid belaste max på databasen, ved eks. at søge gennem tags'ne ..

Eller ville det optimale være et tegnsæt hvor man på den måde konverterer og komprimere teksten, så eks. et ord bliver til et enkelt tegn, eller to tre stykker - det vil naturligvis kræve lidt software for konverteringen, men ville jo hvis tekstsiderne lagredes direkte i databasen få den til at fylde væsentligt mindre, og hvis tegnsættet var opbygget med en god struktur, kunne det være nemt at søge i ..

Men spørgsmålet er igen, vil det alligevel belaste databasen for meget, og vil hastighedsgevinsten forsvinde i sidste ende ??

Og der er vitterligt tale om tusindvis af tekstsider ..

Projektet handler om at ligge et tidsskrift online, ikke som et magasin-hjemmeside noget, men som en database med historiske ting, og muligheden for at læse tidsskrifterne online og søge i dem ..



6 svar postet i denne tråd vises herunder
2 indlæg har modtaget i alt 2 karma
Sorter efter stemmer Sorter efter dato
Måske du kan læse noget ud af dette:
http://www.devarticles.com/c/a/MySQL/Developing-a-Dynamic-Document-Search-in-PHP-Part-1%992/

Men du kan også gøre det ved at bruge MongoDB. Men det er langt fra relationsdatabaser. :)



Jeg ville nok vælge at beholde dokumenterne som filer. Når der så bliver tilføjet et nyt fil, ville jeg med et script læse hvert ord og angive i min database at det dokument indeholder de ord...

På den måde kan du hurtigt sortere efter hvad der indeholder alle ord, lidt af ordene osv.

Ved at have en tabel over ord [ORDTBL] : ORD | ID
En over artikler: [ARTIKELTBL] TITEL | ID | FIL
Og en over hvilke ord artiklerne indeholder: [INDEHOLDERTBL] ORDID | ARTIKELID

Min SQL er lidt rusten, men:

Fold kodeboks ind/udSQL kode 


Ovenstående returnerer en liste over de artikler der indeholder et af ordene. Kan ikke lige huske hvad der skal til for kun at få dem der indeholder alle sørgeord, da jeg i forbindelse med .NET bruger LINQ til at lave min forespørgsler... dog vil jeg tro at du ved at fjerne disinct hurtigt kan lave en anden query hvor der siger at en række skal fremgå X antal gange.

Men altså hvad du kan få databasen til at klare for dig, skal du bruge.. det er ifølge min underviser altid det hurtigste...



Hvorfor ikke bare lave det hele med tags? Altsaa nogle ord der indikere den enkelte artikel, og saa vil soegeformularen foerer til de artikler med de angivende tags :).

Fold kodeboks ind/udPHP kode 



---------------------


Jeg ville nok vælge at beholde dokumenterne som filer. Når der så bliver tilføjet et nyt fil, ville jeg med et script læse hvert ord og angive i min database at det dokument indeholder de ord...

På den måde kan du hurtigt sortere efter hvad der indeholder alle ord, lidt af ordene osv.

Ved at have en tabel over ord [ORDTBL] : ORD | ID
En over artikler: [ARTIKELTBL] TITEL | ID | FIL
Og en over hvilke ord artiklerne indeholder: [INDEHOLDERTBL] ORDID | ARTIKELID

Min SQL er lidt rusten, men:

Fold kodeboks ind/udSQL kode 


Ovenstående returnerer en liste over de artikler der indeholder et af ordene. Kan ikke lige huske hvad der skal til for kun at få dem der indeholder alle sørgeord, da jeg i forbindelse med .NET bruger LINQ til at lave min forespørgsler... dog vil jeg tro at du ved at fjerne disinct hurtigt kan lave en anden query hvor der siger at en række skal fremgå X antal gange.

Men altså hvad du kan få databasen til at klare for dig, skal du bruge.. det er ifølge min underviser altid det hurtigste...


Jeg afproevede din kode her:
http://codepad.org/VTmrQt1K
Det ser ud til at den ikke virker :S



Indlæg senest redigeret d. 01.08.2011 23:32 af Bruger #16025
Hejsa

Tak for jeres svar :)

@Michael: Jeg har ikke så meget forstand på databaser som ikke er relations, så jeg vil studere det lidt nærmere, og også din henvisning til php søgning ..

Er der nogle som har erfaring med de andre databaseformer, om det er noget virkelig godt, eller blot et forsøg på at lave noget andet ??

@Nicky: Det er også den fremgangsmåde jeg har læst mest anbefalet, den med filer, og så et script, og hurtigt og nemt smide nye sider/artikler ind :)

Med hensyn til alle ord, er der en mulighed her, eller faktisk to:
http://www.phpbuilder.com/board/showthread.php?t=10380737

@Daniele: Tags vil ikke blive godt nok, og der vil skulle findes på for mange af dem, og der er et problem i at der tit søges på bestemte sætninger med bestemte udtryk, så derfor må begge være en mulighed - altså hvor tags bliver som en slags kategori-søgning ..

Koden ser ud til at have et par tastefejl: "artikeltbl" og ikke "artikeKtbl" som der står to steder, der er kommet et "K" ind istedet for et "L" ..



Indlæg senest redigeret d. 02.08.2011 08:32 af Bruger #16720
Ja, må desværre erkende at jeg glemte en detalje i mit tidligere indlæg.

Koden er ikke testet, da den blev skrevet direkte i indlægget og jeg ikke har en database med tabeller der hedder det som står der. Selve princippet skulle gerne fungere, da jeg for at være sikker på JOIN-syntaksen skrev en sætning til en database jeg har fra et tidligere projekt.

Anyways, så er princippet stadig det jeg ville frem med, altså hvordan jeg ville opbygge systemet hvis det var mig der stod med lign. udfordring. En database i 3NF der indeholder alle ordene (naturligvis frasorteret ting som er, det, den osv), der gør det hurtigt og nemt at søge i de forskellige artikler :)



Hej igen

Jeg er tidligere faldet over Lucene, ville det være et godt valg, det lyder jo meget fornuftigt, eller er det lidt overkill ? :)




Indlæg senest redigeret d. 02.08.2011 20:46 af Bruger #16720
t