Artikeldatabas – hur lagra brödtexten?

Jag har för avsikt att lägga in en nedlagd tidning i en databas (MySQL) för att göra den sökbar. Materialet är redan inskannat, så det enda jag behöver göra är att designa databasen och fylla på med alla data.

Jag har tänkt mig en huvudtabell med en rad per artikel och grundläggande data i form av årgång, nummer, sidor, titel, undertitel och artikeltext. Sedan blir det ytterligare två tabeller med författare respektive nyckelord och tillhörande kopplingstabeller.

Frågan är bara hur jag ska göra med själva artiklarna och tillhörande bilder. Jag kommer inte på något bra sätt men antar att det finns någon metod som är mer bruklig och förhoppningsvis bättre än andra.

Jag ser till att börja med ingen vettig anledning att över huvud taget blanda in bilderna i databasen, oavsett det är som blob-kolumner eller bara sökvägar, utan tänkte ha dem i ett filsystem och helt enkelt lägga in statiska länkar i html:en (<img src="bilder/1984/blablabla.jpg" etc.). Finns det något bra skäl att inte göra så?

Och sedan artikeltexterna. De ska givetvis vara fulltextindexerade och någonstans måste åtminstone minimal markup komma in i bilden. Det enklaste tycker jag vore att lägga in hela html-klabbet i en text-kolumn i databasen, men finns det något sätt att filtrera indexeringen (annat än med stopword-filen som jag inte kommer åt på mitt webbhotell) så att man inte får med html-taggar och vanliga attributvärden som klassnamn i indexet? För det är ju lite onödigt.

Att spara html-filerna i ett filsystem och lägga in sökvägar till dem i databasen känns inte heller som någon bra lösning eftersom jag i så fall ändå måste ha de rena artikeltexterna för att skapa indexen.

Hur ser de vanligaste lösningarna ut? Är det något särskilt jag inte har nämnt som jag borde tänka extra på? Att datamänden är given från början och att det enbart kommer att läsas från den när alla data väl är intankade gör kanske att man kan bortse från vissa hänsyn man annars behöver ta?

Hur stora mängder data rör det sig om ungefär? Storleksskillnaden mellan 5 MB och 2 TB är ju ganska relvant

Jag har dessvärre fått allt levererat i form av Wordfiler, så det är svårt att uppskatta hur mycket som är bara data. Men totalt är det strax under 500 MB, så det är förhållandevis lite, särskilt med tanke på att även bilderna ingår.

När du skriver ut sökresultatet går det ju alltid att bli av med html-taggar, antingen genom att använda regexpar, eller om språket självt innehåller konstruktioner för att bli av med taggar så det är väl ett mindre problem i sammanhanget?

Om du vill att artiklarna ska kunna fulltextsökas så är juu alternativet att spara dem som blobbar borta, då återstår ju din ide med externa referenser till bilder etc.

Ja, jag tänkte mest på att det är onödigt att de kommer med i indexet och gör det större än nödvändigt (och i värsta fall eventuellt ger felaktiga träffar ifall något sökord skulle råka sammanfalla med ett taggnamn, attributvärde eller liknande, även om risken är liten).

Sitt och plita ner ett format som du testar på några olika artiklar och se hur det fungerar. Om det bara är en brödtext per artikel kan du ju ha en brödtextpost, annars kan du väl ha en separat tabell för det. Jag skulle absolut inte ha HTML-taggar och dylikt i databasen, ju mindre onödigt ju snabbare och smidigare hantering.

Lägg inte artikeltexten i huvudtabellen, ha en separat tabell för alla såna där grejer som återkommer (du har flera artiklar per tidning, så ha en tabell för tidningen, en för författare och en för artikel och kanske en för brödtexter). Har du annan info som redigerare, korrekturläsning etc kanske du ska ha dessa i en separat tabell också om sån info ska in.

Tack för svar. Jag är dock inte helt säker på att jag förstår hur du menar att jag ska göra med artiklarna. Bara sökvägar till dem i databasen och en ren textversion för att skapa index samt en taggad version i filform som sökvägarna leder till? Artiklarna är hur som helst av väldigt blandat slag. En del är korta och innehåller bara ett stycke, andra kan innehålla åtskilliga stycken med underrubriker och ibland tabeller och en hel del bilder med bildtexter.

Det beror på vad du har för serversystem och dylikt. Jag skulle gissa att det fungerar fint att lägga in all text som fritext (då utan HTML) och lägga CSS och script och sånt i ett skal. Då har du ett ID fält för varje artikel som du kan låsa till brödtexterna om du har dessa i en separat tabell.

Typ så här:

artiklar:

artikel_ID
artikel_text

brödtext:

artikel_ID
abstract_text

tidskrift:

tidskrift_ID
artikel

(i det här fallet skulle det bli en post per artikel så en tidskrift med 10 artiklar skulle ha 10 poster i tidskrift-tabellen). Man kan givetvis göra en post med alla artiklar också men jag skulle nog hellre göra flera poster och lägga upp alla andra grejer i en separat tabell.

Ok, tack. Jag är inte helt säker på att allt är helt tillämpligt på mitt material. Jag får testa lite och fundera vidare.

Nu vet jag att du specifikt nämnde MySQL, men jag skrev ett artikelarkiv precis som du beskriver i Notes/Domino en gång i tiden. För dokumentbaserade database är en NoSQL-lösning som Domino betydligt bättre, IMHO.

Dessutom får du både fulltextsökning och webbpublicering "gratis" i Domino. Borde ta max en halvtimme att hacka ihop en fungerande databas, och sedan några timmar till att skapa ett snyggt webbgränssnitt.

Här är ett exempel på en site som är byggd helt i Domino (med Bootstrap och jQuery för att göra det snyggt på webben): http://www.texasswede.com/
Varje sida är ett eget dokument, där texten ligger som rich text.

Så här ser det ut in Notes-klienten:
http://i.imgur.com/zmRNZwc.gif (navigering och vy)
http://i.imgur.com/EZ8pF3a.gif (innehållssida med bilder och länkar)

Har inte lagt ner någon tid på att göra klienten snygg (den här databasen7applikationen är bara för mitt eget bruk), men det är inte svårt.

Tack. Ja, jag verkar hela tiden få alltfler anledningar att börja titta närmare på NoSQL-lösningar också.