Vinnaren i pepparkakshustävlingen!
2012-02-02, 20:31
  #1
Medlem
FlyingMachines avatar
Ponera att man besitter en databas över bilar. För att bäst hantera denna stora databasen kan det tänkas att man till varje bil vill binda ett antal nyckelord, för att vid sökning underlätta för användaren. Frågan är då hur detta implementeras på ett sätt som inte ödslar allt för mycket serverresurser.

Lösning 1: För varje bil lagrar du en array innehållande nyckelorden.
Lösning 2: Du skapar ytterligare en tabell innehållande nyckelord, och dessa modelleras efter ett N-M-förhållande (nu utgår jag från att ni är bekanta med ER-modellering).

Lösning 1 ryker direkt på grund av ineffektivitet. Säg att en användare vill ha bilar med rosa läderklädsel; sökskriptet måste då leta igenom alla bilars nyckelordsarray.

Lösning 2 är desto enklare: SQL-frågan för bilar med rosa läderklädsel blir helt enkelt
Kod:
SELECT car FROM keyword_relation WHERE keyword='rosa läder';

Så, är detta den effektivaste/resurssnålaste lösningen, eller vad säger ni?
Citera
2012-02-02, 20:51
  #2
Medlem
Inlägget är i PHP-forumet, men du pratar rätt mycket om databaser, så jag vet inte om du har några särskilda begränsningar för hur det här ska göras? Är mängden söktermer begränsad? Tittat på fulltext-sökning? "ett sätt som inte ödslar allt för mycket serverresurser." är antagligen inte det mest precisa jag läst heller ..
__________________
Senast redigerad av Koenigsegg 2012-02-02 kl. 20:55.
Citera
2012-02-02, 21:22
  #3
Medlem
The Barrs avatar
Tja, säg att du har en tabell för läderklädsel. Där kan du ha en tabell som heter färg. Du kan skapa en läderklädsel som är rosa.

Sen har du en bil. Bil har ett fält för vilken läderklädsel den har. Eller så ar du en kopplingtstabell mellan läderklädsel och bilar.

Om du ska hämta alla bilar som har rosa läderklädsel hämtar du först nyckeln för denna rosa läderklädsel. Sen söker du igenom Bilarna efter de som har rätt nyckel för läderklädseln. Det går snabbt eftersom du har index på den.

Eller ett annat mer passande exempel?
Citera
2012-02-02, 22:18
  #4
Medlem
Bongomans avatar
I många fall bygger man attributen i en separat tabell i numeriska värden. Du har tre värden i en sådan tabell. Värdet, attributtyp och huvudpostens id. Sedan har du en tabell där du sparar attributtyp, textvärde och språk. På så sätt kan du dels lägga till fler språk, dels går sökningarna blixtsnabbt och det är lätt att förändra och lägga till olika värden. Speciellt vid annonsering är det effektivt för du kan inte ha aluminium som klädsel, bara fälgar och färgen är aldrig automat. Man kommer också ifrån att folk vill ha knasiga nyckelord.

Men hur får man då ut allt och går det snabbt? Ja, du har en tabell med nyckelord som är ganska liten. Max några hundra rader som ska sökas igenom som text. Därifrån JOINar man in attributtabellen som är enorm men indexerad effektivt och till sist JOINar man in dina bilar på numerisk nivå återigen.

Just detta systemet har jag i min e-handel och det fungerar bra.
Citera
2012-02-03, 01:36
  #5
Medlem
FlyingMachines avatar
Citat:
Ursprungligen postat av Koenigsegg
Inlägget är i PHP-forumet, men du pratar rätt mycket om databaser, så jag vet inte om du har några särskilda begränsningar för hur det här ska göras? Är mängden söktermer begränsad? Tittat på fulltext-sökning? "ett sätt som inte ödslar allt för mycket serverresurser." är antagligen inte det mest precisa jag läst heller ..
Så tokigt det kan gå. Jag har inga som helst begränsningar i form av databas, så tråden skulle legat bättre i databasforumet. Har meddelat moderator.

Citat:
Ursprungligen postat av The Barr
Tja, säg att du har en tabell för läderklädsel. Där kan du ha en tabell som heter färg. Du kan skapa en läderklädsel som är rosa.

Sen har du en bil. Bil har ett fält för vilken läderklädsel den har. Eller så ar du en kopplingtstabell mellan läderklädsel och bilar.

Om du ska hämta alla bilar som har rosa läderklädsel hämtar du först nyckeln för denna rosa läderklädsel. Sen söker du igenom Bilarna efter de som har rätt nyckel för läderklädseln. Det går snabbt eftersom du har index på den.

Eller ett annat mer passande exempel?
Kruxet med den lösningen är att man i sådant fall måste skapa en tabell per egenskap. Säg dessutom att man vill söka efter en cabriolet med snurrande fälgar och en discokula i backspegeln. Tänk dig vilken databasstruktur en sådan lösning skulle behövt.

Citat:
Ursprungligen postat av Bongoman
I många fall bygger man attributen i en separat tabell i numeriska värden. Du har tre värden i en sådan tabell. Värdet, attributtyp och huvudpostens id. Sedan har du en tabell där du sparar attributtyp, textvärde och språk. På så sätt kan du dels lägga till fler språk, dels går sökningarna blixtsnabbt och det är lätt att förändra och lägga till olika värden. Speciellt vid annonsering är det effektivt för du kan inte ha aluminium som klädsel, bara fälgar och färgen är aldrig automat. Man kommer också ifrån att folk vill ha knasiga nyckelord.

Men hur får man då ut allt och går det snabbt? Ja, du har en tabell med nyckelord som är ganska liten. Max några hundra rader som ska sökas igenom som text. Därifrån JOINar man in attributtabellen som är enorm men indexerad effektivt och till sist JOINar man in dina bilar på numerisk nivå återigen.

Just detta systemet har jag i min e-handel och det fungerar bra.
Det där ringer faktiskt inte helt illa i mina öron. Tror nog jag ska ge mig på ett försök att implementera något sådant.
Citera
2012-02-03, 07:09
  #6
Medlem
DigGaNs avatar
PHP -> Databaser
/Moderator
Citera
2012-02-03, 09:51
  #7
Medlem
The Barrs avatar
Citat:
Ursprungligen postat av FlyingMachine
Kruxet med den lösningen är att man i sådant fall måste skapa en tabell per egenskap. Säg dessutom att man vill söka efter en cabriolet med snurrande fälgar och en discokula i backspegeln. Tänk dig vilken databasstruktur en sådan lösning skulle behövt.

Beror ju på hur många olika egenskaper som är aktuella. I ditt exempel var det bara "ett antal". Men vid närmare eftertanke så håller jag med om att bongomans modell bör vara mer lämplig. Mindre och simplare, samtidigt som man egentligen inte har något behov av att alla egenskaper av en vis typ, rosa läderklädsel till exempel, går till en viss dataentitet. Det är ju inte är ett speciellt dynamiskt förhållande, där det exempelvis inte är aktuellt att färga om alla bilar med rosa läderklädsel genom att byta namn på rosa läderklädsel till lila läderklädsel.

Däremot kan man tänka sig att min modell skulle vara mer aktuell om din bil istället består av olika delar som verkligen är lika, t.ex. med ett specifikt artikelnummer. Då skulle du exempelvis ha en tabell med fälgar och dess egenskaper med artikelnummer som id och koppla denna till en bil. Behöver du sedan ändra informationen om just denna fälgen så slår det igenom till alla bilar som är utrustade med just den fälgen.
Citera

Stöd Flashback

Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!

Stöd Flashback