Databasstruktur

Hej!

Jag håller på att fixa lite grejer. I min webbapplikation ska man kunna lägga upp saker, och varje sak ska kunna kopplas till ett eller flera nyckelord. Det jag undrar är vad som blir effektivast, en one-to-many-relation där jag har en nyckelordstabell med kolumnerna grej_id och nyckelord, eller en many-to-many där jag har två tabeller, en med bara nyckelord och en som mappar grejer till nyckelord. Jag inser såklart att det första alternativet kommer ta mycket mer utrymme, eftersom de flesta nyckelord kommer förekomma flera gånger, men blir det inte också mer "optimerat"?

1. Ett nyckelord kan kopplas från en till många saker
2. En sak kan kopplas från ett till många nyckelord

Med andra ord du bör använda many-to-many eftersom det är så som relationen är Oftast är det väldigt bra att forumlera relationerna i klartext, så som jag gjorde ovan, då brukar man enkelt kunna få fram vilken relation "problemet" har.

Alternativ ett är helt värdelöst dvs felaktig databasdesign som skulle innebära en rejäl rendundans i databasen.

I praktiken alltså tre tabeller - many-to-many realiseras med två one-to-many:

1. Grej-tabellen (grejid, grejattribut ... )
2. Nyckelord-tabellen (nyckelordsid, nyckelord)
3. Kopplingstabellen (grejid, nyckelordsid)

(Bonus är att du också kan kategorisera dina nyckelord:
4. Kategoritabell (kategorid, kategoritext)
5. Nyckelkategoritabell (kategoriid, nyckelordsid)

Tack! Jorå, jag är medveten om att det blir massa redundans med alt 1, men visst måste det gå mycket snabbare?

Om jag t.ex. ska leta fram en grej efter ett nyckelord krävs först en scanning av nyckel-ordstabell, sedan en scanning av grejtabell med alternativ ett. Med alternativ två krävs först en scanning av nyckelordstabell, sedan en scanning av associationstabell och sedan en scanning av grejtabell. Även vid insert blir det mycket mer jobb, först en scanning av nyckelordstabell (sannolikt måste hela scannas igenom eftersom de flesta nyckelord till att börja med inte kommer ge match), sedan eventuellt en insert i nyckelordstabell, insert i associationstabell och sist insert i grejtabell. Är det värt att offra massa prestanda för att slippa redundans?

Fast har du en jävligt stor tabell med grejer så är det möjligt att alternativ 1 blir långsammare. Sen kan man ju även fråga sig varför du oroar dig så för prestandan. Som regel när det gäller såna här grejer så är det bäst att göra en snygg design från början och om resultatet i slutändan blir för slött så får man optimera det då.

En aspekt till är risken för felinmatningar.

Om du - eller ännu vanligare flera olika personer - skall skriva in nyckelordet "Riesenschnauscher" på flera olika grejer, hur stora är oddsen tror du att du kommer att få många olika varianter på detta ord?

Man ser ju till att användaren inte kan välja fritt vilken indata/nyckelord ska matas in. När det gäller en webbapplikation så fungerar dropdown-boxar bra för ett sådant ändamål.

Njaeäh, sällan när man leker med nyckelord... Kika flickr till exempel. Svårt att få snygga dropdowns med X*10^5 olika alternativ

Drar upp tråden igen! Har köpt era argument och har nu en fullständigt normaliserad db. Nu till kruxet; jag vill söka efter en grej som har både nyckelordet A och nyckelordet B.

kommer ju självklart inte ge mig några resultat, eftersom det inte finns några rader efter JOIN:en som har både nyckelord A och B. Hur göra?

Istället för AND - så använd OR - så får du de som har antingen den ena eller den andra.

Dvs:

exists:


join:

Ursäkta min dryghet ärade moderator men - DAAH!
Grejen är att jag vill ha möjlighet att hämta bara de med båda (eller flera) nyckelorden. En fungerande men ful lösning hade varit att köra din fråga och sedan sortera bort de man inte vill ha i "runtomkring-programmet", ett PHP-skript i det här fallet. Desvärre funkar inte det heller eftersom min fråga inte alls ser ut så, utan grupperas efter grej_id i ett senare skede och alltså kommer ändå bara ett record, med ett keyword, tillbaka från frågan. Men tack iallaflal!

Tack! Det där kan jag nog använda.