[PHP] Search engine verbeteringen

[Renegade]

Ik heb zelf een searchengine geschreven in PHP . De indexeringsroutine werkt behoorlijk, alleen zijn verbeteringen altijd welkom.

de source is te vinden op:

http://www.orthoeurope.com/search/select_from.phps

De MySQL tabel is als volgt opgebouwd:

[b]
CREATE TABLE search (
id int(11) NOT NULL auto_increment,
url varchar(255),
content text NOT NULL,
description varchar(255),
title varchar(255),
PRIMARY KEY (id),
UNIQUE url (url),
KEY url_2 (url)
);
[b/]

Iemand op/aanmerkingen of verbeteringen

[Verwijderd]

Heb je niet ergens een online demo?

[dusty]

Leuk idee maar ik vraag mij af hoe groot je de search engine wilt maken.

Als je namelijk heel veel "bestanden" gaat gebruiken om op te zoeken is er een betere methode om een search in elkaar te gooien en de andere methode werkt veel sneller. (bij veel informatie)

[Renegade]

Momenteel doorzoekt dit PHP bestand een directory die ik opgeef in een formulier, bijvoorbeeld /disk1/home/ortho/html

in deze directory zal het bestand gaan zoeken op .htm en .html bestanden, en deze vervolgens gaan indexeren in een database zetten. Bestaat het bestand nog niet in de database, dan zal hij deze toevoegen (locatie, inhoud, titel, enz..), bestaat het bestand al wel, dan zal hij deze gaan updaten.

Dit leek me wel een redelijk praktische methode, alleen moet deze machine al ruim 350 bestanden gaan indexeren, en dus ben ik nieuwsgierig naar betere manieren.

Wie heeft er een goede verbetering?

edit:

trouwens, de demo is te vinden op:

http://www.orthoeurope.com/search/select.php

als locatie kun je opgeven:

/usr/local/apache/users/ortho/html

[dusty]

Aanschouw het volgende en huiver

even een voorbeeldje als een zoekmachine voor url's.

code:

LinkIndex
LinkID , Url , Omschrijving, DateIndexed

MyWords_<word>
LinkID

Elk woord krijgt dynamisch zijn eigen tabel.

[edit: ohja bold binnen code kan niet ]

[Renegade]

Elk woord z'n eigen tabel

Hoe groot mag dat wel niet worden bij het aantal documenten dat ik heb?

[Verwijderd]

Ik krijg allemaal fouten als ik naar de demo ga en iets invoer.....

maar wel leuk! als ie het een keer doet (ironisch)

[luc]

Op maandag 19 maart 2001 20:53 schreef Mr.Eminem het volgende:
Ik krijg allemaal fouten als ik naar de demo ga en iets invoer.....

maar wel leuk! als ie het een keer doet (ironisch)

Volgens mij begrijp jij het probleem niet helemaal, je snapt zeker niet wat de demo eigenlijk uitbeeld... zou het verhaaltje nog maar 's lezen.

[dusty]

Op maandag 19 maart 2001 20:38 schreef Renegade het volgende:
Elk woord z'n eigen tabel

Hoe groot mag dat wel niet worden bij het Aantal documenten dat ik heb?

Prettig Idee toch ?

Een nachtmerrie voor een database expert, en een fanatiek aanhanger, voor een juist database model.

Helaas is dit een van de dingen die je moeilijk anders kan doen wil je het hele systeem heel snel krijgen.

Als je bijvoorbeeld 5 miljoen worden hebt krijg je dus op jouw manier een tabel met 5 miljoen records.. -slik- Ga daar eens op zoeken met 5 trefwoorden Moet je in iedergeval EEN query ALLE 5 miljoen records doorlopen -> Niet fijn voor je database.

OP de alternatieve manier waar elke woord zijn eigen tabel krijgt (uiteraard begin je die tabllen allemaal hetzelfde zodat het makkelijk herkenbaar is..) betekent dat je misschien wel 5.000 tabellen krijgt. Maar overal 1000 records in. Zoek je nu op 5 trefwoorden is het een kwestie van de linkID's zoeken die in elke tabel van "het woord" voorkomt. Wat dus erg snel gaat omdat er maar 1000 records inzitten EN omdat het integers zijn. Je gaat namelijk ook niet kijken of een woord "gelijk" aan een zoekterm is (char). Aangezien het woord aangeeft welke tabel het moet zijn.

Dit betekent dus dat je al op 2 verschillende manieren een snelheid winst krijgt.

Ook is je systeem hierdoor iets flexibeler en kan je dus meer opties gaan toevoegen. ( leuke statistieken -> Welke link komt het meest voor etc etc )

[edit: I blame my spelling mistakes all on Jaymz!]

[Verwijderd]

In theorie een leuk verhaal dat van Dusty alleen praktisch niet uitvoerbaar.

Wat moet de zoekmachine kunnen (de bekende zoekmachines op het web zijn op vershillende principes gebaseerd)?
Wil je gebruik maken van fulltext search?
Van trefwoorden, van categorien etc...
Een combinatie van deze zaken is ook interessant.

Je moet je afvragen of je de hele tekst op wilt slaan of alleen de trefwoorden (titel,META).
Bij trefwoorden wordt het al een stuk eenvoudiger (lees compacter/sneller).
Als je toch de hele tekst op ga slaan
is het misschien slim om te kijken naar een goed algoritme om woorden in teksten te zoeken (bijvoorbeeld methode van Boyer-Moore).
Hoe je datamodel er uit gaat zien is natuurlijk sterk afhankelijk van de gekozen manier.

Welke database gebruik je/wil je ondersteunen?

Een goede zoekmachine die ook nog eens snel is = goud waard.

[edit]
Als je de search van GoT gebruikt vind ie oa [topic=104674]
[\edit]

[Renegade]

Op dinsdag 20 maart 2001 09:29 schreef sjako het volgende:
In theorie een leuk verhaal dat van Dusty alleen praktisch niet uitvoerbaar.

Nou, met heel veel geduld misschien...

Wat moet de zoekmachine kunnen (de bekende zoekmachines op het web zijn op vershillende principes gebaseerd)?
Wil je gebruik maken van fulltext search?
Van trefwoorden, van categorien etc...
Een combinatie van deze zaken is ook interessant.

Het liefst zoeken op trefwoorden, of een combinatie van trefwoorden (zinnen e.d.)

Je moet je afvragen of je de hele tekst op wilt slaan of alleen de trefwoorden (titel,META).

Ok, daar kan ik kort over zijn, complete teksten dus.

Als je toch de hele tekst op ga slaan
is het misschien slim om te kijken naar een goed algoritme om woorden in teksten te zoeken (bijvoorbeeld methode van Boyer-Moore).

Boyer-Moore

Welke database gebruik je/wil je ondersteunen?

MySQL

Een goede zoekmachine die ook nog eens snel is = goud waard.

*duhhh.......*

Maar in ieder geval bedankt voor het commentaar tot zover allemaal. Graag verdere reacties.

[dusty]

Op dinsdag 20 maart 2001 09:29 schreef sjako het volgende:
In theorie een leuk verhaal dat van Dusty alleen praktisch niet uitvoerbaar.

Wedden ?

[Renegade]

Wedden?

Ok, ik heb het gevoel dat het technische nieveau van de discussie me vanaf hier boven het hoofd zal gaan.....

*oh ja?*
**ja**
*waarom dan?*
**daarom**
*oh ja?*
**ja**

[chem]

dit wordt nog een leuk topic

waarom niet een gedeelte van de text indexen op basis van het verwijderen van ruis & positie van de text (bovenaan, onderaan, headers, footers en titles), en tabel met woord-in-file (3 columns: PK='woord', en 'filename', 'hits'). Dan zoek je in welke files het woord (woorden) voorkomt, en je hebt meteen een hit-ratio...

volledige text is nl. wel heel veel vermoed ik...

[Verwijderd]

Dusty : Wedden is altijd grappig.

Ik bedoelde met mijn opmerking te zeggen dat je bij jouw dynamische model tegen een aantal beperkingen aan ga lopen (waarvan beheer van je db 1 van de belangrijkste zaken zal zijn).

Jij gaat uit van 'maar liefst' 5000 woorden.
Ik weet zeker dat het een veelvoud gaat worden.
Je zult voor alle (nieuwe) woorden een check moeten doen of er al een tabel bestaat voor dit woord (of een tabel creeren/select uitvoeren en dan de foutmelding afvangen).
Dat komt de performance ook niet ten goede.

Veel logischer is het om de woorden waarvoor jij een tabel wilt maken, op te nemen in 1 tabel (dat doe je eigenlijk met het aanmaken van een nieuwe tabel ook al) of in meerdere tabellen bijv tabel per 1e letter vh woord (of wat voor constructie je ook wilt verzinnen).

Je hebt nu een tabel met (volgens jou voorbeeld) 5000 records.
Daar is prima in te zoeken.

Door deze woorden te linken aan 1 of meerdere URL's (zie jou eigen constructie) ben je net zo flexiel en heb je een normaal datamodel, waarbij het beheer ook normaal te doen is.

Als je de weddenschap aan wilt gaan hou ik me beschikbaar voor het leveren van een aantal URLS.

Grappig als je gekwoot wordt

Renegade : u vraagt, wij draaien

Chem : Er is recentelijk geklaagd dat topics weinig inhoud/uitdaging hebben.
Dusty en ik gaan ons best doen

[Verwijderd]

Op dinsdag 20 maart 2001 10:53 schreef Renegade het volgende:

Boyer-Moore

Zal ff voor je zoeken.....

[Renegade]

Op dinsdag 20 maart 2001 12:05 schreef chem het volgende:
dit wordt nog een leuk topic

waarom niet een gedeelte van de text indexen op basis van het verwijderen van ruis & positie van de text (bovenaan, onderaan, headers, footers en titles), en tabel met woord-in-file (3 columns: PK='woord', en 'filename', 'hits'). Dan zoek je in welke files het woord (woorden) voorkomt, en je hebt meteen een hit-ratio...

klinkt wel leuk, je bedoelt gewoon alle html eruit filteren, per pagina de inhoud in een file zetten, en de gezochte woorden gaan filteren

volledige text is nl. wel heel veel vermoed ik...

[sarcasme modus]
mwoah, +- 350 bestanden met gemiddeld zo'n 4 pagina's aan tekst..?
[/sarcasme modus]

[Renegade]

Op dinsdag 20 maart 2001 12:08 schreef sjako het volgende:
Dusty : Wedden is altijd grappig.

Ik bedoelde met mijn opmerking te zeggen dat je bij jouw dynamische model tegen een aantal beperkingen aan ga lopen (waarvan beheer van je db 1 van de belangrijkste zaken zal zijn).

Jij gaat uit van 'maar liefst' 5000 woorden.
Ik weet zeker dat het een veelvoud gaat worden.

Ow? *lol*
maar dat zal kloppen, er zullen nog veel meer woorden in gaan komen.
Langzaam maar zeker is het de bedoeling dat er geschreven materiaal wordt omgezet naar de website, en dus ook doorzocht kan gaan worden.
Het aantal zal dus langzaam maar zeker gaan uitbreiden.

Je zult voor alle (nieuwe) woorden een check moeten doen of er al een tabel bestaat voor dit woord (of een tabel creeren/select uitvoeren en dan de foutmelding afvangen).
Dat komt de performance ook niet ten goede.

Veel logischer is het om de woorden waarvoor jij een tabel wilt maken, op te nemen in 1 tabel (dat doe je eigenlijk met het aanmaken van een nieuwe tabel ook al) of in meerdere tabellen bijv tabel per 1e letter vh woord (of wat voor constructie je ook wilt verzinnen).

Ok, mij is geleerd om databases te gaan normaliseren, om zo de database snel te houden, en recursie tegen te gaan. Deze oplossing lijkt me redelijk praktisch daarvoor.

Maar zou je dan de locatie(s) waar het woord voorkomt per woord moeten gaan opslaan (bijv woord1 staat in pagina1.htm en in pagina2.htm), want dat lijkt me weer behoorlijk omslachtig.

Of zou je de locaties weer apart gaan indexeren en m.b.v. ID's gaan koppelen aan de woorden? (bijvoorbeeld woord1 staat in ID1, ID4, ID6, en zie ID's verwijzen naar de locatie van de bestanden)

(kunnen we het nog volgen )

Je hebt nu een tabel met (volgens jou voorbeeld) 5000 records.
Daar is prima in te zoeken.

Door deze woorden te linken aan 1 of meerdere URL's (zie jou eigen constructie) ben je net zo flexibel en heb je een normaal datamodel, waarbij het beheer ook normaal te doen is.

Renegade : u vraagt, wij draaien

Mijn dank is groot.

[chem]

Op dinsdag 20 maart 2001 12:11 schreef Renegade het volgende:

[..]

klinkt wel leuk, je bedoelt gewoon alle html eruit filteren, per pagina de inhoud in een file zetten, en de gezochte woorden gaan filteren

dat is precies wat ik bedoel.
En dan split je je text op ' ' oid, en kijk je vv. of 't een ruiswoord is (bv de/het/een/punctuatie (?!:@$)) en zo niet dan voeg je 'm toe...

da's makkelijk te maken, en snel dunkt <font color="#df040f">* chem</font>

[Renegade]

Op dinsdag 20 maart 2001 12:38 schreef chem het volgende:

[..]

dat is precies wat ik bedoel.
En dan split je je text op ' ' oid, en kijk je vv. of 't een ruiswoord is (bv de/het/een/punctuatie (?!:@$)) en zo niet dan voeg je 'm toe...

da's makkelijk te maken, en snel dunkt <font color="#df040f">* chem</font>

Ik heb aan zoiets ziten te denken, maar om alle text in een file te plaatsen zal behoorlijk wat van de database evergen om te gaan doorzoeken, of zie ik het nu heel erg verkeerd? (om nog maar te zwijgen in welk type je de inhoud moet plaatsen, largeblob ofzo?)

[dusty]

Dusty : Wedden is altijd grappig.

Yup

Ik bedoelde met mijn opmerking te zeggen dat je bij jouw dynamische model tegen een aantal beperkingen aan ga lopen (waarvan beheer van je db 1 van de belangrijkste zaken zal zijn).

Het beheer wordt ook niet handmatig gedaan (gelukkig) daar zorgt "de spider" wel voor.

Jij gaat uit van 'maar liefst' 5000 woorden.
Ik weet zeker dat het een veelvoud gaat worden.
Je zult voor alle (nieuwe) woorden een check moeten doen of er al een tabel bestaat voor dit woord (of een tabel creeren/select uitvoeren en dan de foutmelding afvangen).
Dat komt de performance ook niet ten goede.

Maar dat is alleen bij het toevoegen van een nieuwe url/bestand. Ook kan je stellen dat verschillende worden (excluding words) niet hoeven ( the , 1 letterige woorden, 2 letterige woorden , een ) etc. etc. Wat er ook gedaan kan worden is een "woordenboek" van de woorden die wel gebruikt mogen worden. daar is allemaal wel omheen te komen.
5000 woorden is inderdaad wel te doen en het zal inderdaad oplopen gaan we naar 1 miljoen woorden totaal. tabel met 1 miljoen records doorzoeken. Wordt helemaal leuk als je 1 miljoen pagina's gaat indexeren.

Veel logischer is het om de woorden waarvoor jij een tabel wilt maken, op te nemen in 1 tabel (dat doe je eigenlijk met het aanmaken van een nieuwe tabel ook al) of in meerdere tabellen bijv tabel per 1e letter vh woord (of wat voor constructie je ook wilt verzinnen).

Je hebt nu een tabel met (volgens jou voorbeeld) 5000 records.
Daar is prima in te zoeken.

Door deze woorden te linken aan 1 of meerdere URL's (zie jou eigen constructie) ben je net zo flexiel en heb je een normaal datamodel, waarbij het beheer ook normaal te doen is.

En toen hadden we 1 miljoen woorden. dus heb je een tabel met de woorden in. dat woord is goed te vinden. Dan ga je die ID zoeken in het tabel waar alle woorden aan de id's van de url's zijn gekoppeld. Dat zullen weer 1 miljoen records zijn.

Als je de weddenschap aan wilt gaan hou ik me beschikbaar voor het leveren van een aantal URLS.

Ik zal thuis eens wat backups doorspitten of ik mijn code kan vinden..

Grappig als je gekwoot wordt

Met genoegen

Chem : Er is recentelijk geklaagd dat topics weinig inhoud/uitdaging hebben.
Dusty en ik gaan ons best doen

ben ik mee eens

[Verwijderd]

Volgens mij had php een Boyer Moore functie, met uitleg erbij, maar die kan ik even niet vinden.. als ik hem vind geef ik wel een link.

[Verwijderd]

Boyer-Moore : http://www.vuiksvertier.nl/wetenschap/aardvark.htm

[Renegade]

Sortering van achter naar voor per woord?

Grappig idee, maar je komt nog steeds niet van het feit af dat je het spul wel in een of andere database zal moeten gooien, zal de discussie blijven wat hiervoor de beste methode is... toch?

[Verwijderd]

Op dinsdag 20 maart 2001 12:44 schreef dusty het volgende:

Maar dat is alleen bij het toevoegen van een nieuwe url/bestand.

Nee, ook bij het zoeken weet je niet of de tabel bestaat. Als ik zoek op "sjako" en er bestaat geen tabel "sjako" zul je toch je foutmelding af moeten vangen (is op zich ook geen probleem, alleen niet mijn favoriete manier van proggen).

Ook kan je stellen dat verschillende worden (excluding words) niet hoeven ( the , 1 letterige woorden, 2 letterige woorden , een ) etc. etc. Wat er ook gedaan kan worden is een "woordenboek" van de woorden die wel gebruikt mogen worden. daar is allemaal wel omheen te komen.

Dat is altijd zo, welke oplossing je ook kiest.

5000 woorden is inderdaad wel te doen en het zal inderdaad oplopen gaan we naar 1 miljoen woorden totaal. tabel met 1 miljoen records doorzoeken. Wordt helemaal leuk als je 1 miljoen pagina's gaat indexeren.

En jij hebt 1 miljoen tabellen MySQL Beheersbaar:?

En toen hadden we 1 miljoen woorden. dus heb je een tabel met de woorden in. dat woord is goed te vinden. Dan ga je die ID zoeken in het tabel waar alle woorden aan de id's van de url's zijn gekoppeld. Dat zullen weer 1 miljoen records zijn.

Dat het zoeken in grote hoeveelheden gegevens niet snel gaat moge duidelijk zijn. Je beperkt je resultaat natuurlijk door zoveel mogelijk woorden op te geven (maar dan wordt het ook weer trager).

Het belangrijkste van het hele verhaal is op de juiste manier de juiste data wegschrijven.
Zo min mogelijk opslaan en zoveel mogelijk terug kunnen vinden?
Redundante data opslaan?
Woorden die vaak samen voorkomen samen opslaan?

Je kunt je data ook op verschillende manieren benaderen.
Je kunt bijvoorbeeld eerst in een lijst met categorien gaan zoeken. Daarna, indien nodig, in een tabel keywords, en daarna eventueel nog full text.

Kortom, genoeg om over na te denken.

Ik zal thuis eens wat backups doorspitten of ik mijn code kan vinden..

Kijk je dan ook nog eens naar de doc's over het order by 'probleem'?

[Verwijderd]

Op dinsdag 20 maart 2001 13:23 schreef Renegade het volgende:
.. maar je komt nog steeds niet van het feit af dat je het spul wel in een of andere database zal moeten gooien, zal de discussie blijven wat hiervoor de beste methode is... toch?

De methode van BM gaat over het zoeken in (grote) teksten.
Je kunt je text gewoon in z'n geheel opslaan (of op je FS/WWW laten staan).

Discussie is inderdaad "hoe vind ik de relevante tekst zo snel mogelijk terug"
(indexeren).
Je wilt niet telkens alle teksten gaan doorzoeken maar slechts de belangrijkste woorden (die staan bijvoorbeeld in de eerste alinea of in de laatste of in de titel, zie je studieboeken Nederlands).

[Renegade]

Op dinsdag 20 maart 2001 13:32 schreef sjako het volgende:

[..]

De methode van BM gaat over het zoeken in (grote) teksten.
Je kunt je text gewoon in z'n geheel opslaan (of op je FS/WWW laten staan).

Discussie is inderdaad "hoe vind ik de relevante tekst zo snel mogelijk terug"
(indexeren).
Je wilt niet telkens alle teksten gaan doorzoeken maar slechts de belangrijkste woorden (die staan bijvoorbeeld in de eerste alinea of in de laatste of in de titel, zie je studieboeken Nederlands).

Dat klopt, het liefst zou ik het spul niet in een database gooien, maar "real time" doorzoeken, dat voorkomt dat de informatie veroudert is, maar het doorzoeken wordt dan alleen wel gigantisch traag (..over het algemeen). Met een database kun je die traagheid gedeeltelijk afvangen, maar heb je dat up to date probleem.

[chem]

Op dinsdag 20 maart 2001 12:43 schreef Renegade het volgende:

[..]

Ik heb aan zoiets ziten te denken, maar om alle text in een file te plaatsen zal behoorlijk wat van de database evergen om te gaan doorzoeken, of zie ik het nu heel erg verkeerd? (om nog maar te zwijgen in welk type je de inhoud moet plaatsen, largeblob ofzo?)

nee, nee, niet alle text in een veld plaatsen...
je opent file x
pak de text, filter de html en andere voor de hand liggende troep eruit
explode op spatie tot array van tekens & woorden
voeg woorden die /geen/ ruis toe als 1 record toe aan de DB, bij herhaling update je het # hits, evt. met factor (bv. onderaan is 0.2, bovenaan 0.8), met filename erbij
je krijgt dus PER WOORD PER FILE een record. Stel je file heeft 10,000 woorden waarvan 3,500 uniek dan heb je dus 3,500 records per file.

snappie? En dat levert een flinke table maar met indeces ben je daar ZO doorheen... evt. kun je dit nog normalizeren: aantal, woord en file over 3 tables splitsen zodat de db errug klein wordt in filesize.

[dusty]

Op dinsdag 20 maart 2001 13:27 schreef sjako het volgende:
Kijk je dan ook nog eens naar de doc's over het order by 'probleem'?

Ik weet zeker dat ik de pagina waarop het 'probleem' werdt uitgelegd had uitgeprint. Die heb ik zeer zeker niet in digitale vorm staan. Maar van alles was ik ooit heb geprogrammeerd heb ik minimaal een backup.

De Search Engine heeft altijd een problemen. Elke oplossing die je kiest heeft nadelen en voordelen.

Over het algemeen als je een hele grote search engine krijgt ga je toch de database opsplitsen in verschillende machines. Waardoor je dus kan opsplitsen in begin letter van het woord.

Daargelaten zal ik wel zeggen dat het inderdaad beter is om gewoon alles in een tabel te stoppen als je relatief weinig records verwacht. ( kunnen we nu natuurlijk gaan discussieren over wat relatief weinig is )

[Verwijderd]

Toevallig ben ik enige tijd geleden ook bezig geweest met een zoekmasjien met MySQL als database maar dan gebaseerd op Perl. Ik ben uitgegaan van een bestaande, nl Perlfect, en heb deze naar eigen wensen aangepast. Wel moest ik zelf het ontwerp van de database bedenken. Ik ben als volgt te werk gegaan: je hebt woorden en bestanden (URL's). Hun relatie onderling is van het type M:N, 1 woord kan in N bestanden voorkomen en een bestand kan M woorden bevatten. De klassieke oplossing hiervoor is drie tabellen maken: woorden, bestanden en een crosstabel waar de keys van de eerste 2 aan elkaar gerelateerd worden.
Verder heb ik ook de uitzonderingen (zoals 'de', 'het', 'een', enz) in het bestand met woorden opgenomen (met een speciaal vlaggetje) want dit waren er ook al meer dan 500. Deze woorden zijn trouwens makkelijk te vinden door wat tellertjes bij te houden. In dit geval in hoeveel bestanden een woord voorkomt. Door ze na het indexeren hierop te rangschikken vind je die worden als 'soms, 'altijd' en dergelijke.
Maar ja nu het opzoeken nog. Eén woord vinden gaat nog wel, maar combinaties en met operatoren zoals AND, OR en NOT, dat is nog wel iets waar ik aan moet werken. Goede ideeen daar over zijn altijd welkom.

*Edit: Typo

[Verwijderd]

Op dinsdag 20 maart 2001 13:54 schreef dusty het volgende:
....
Daargelaten zal ik wel zeggen dat het inderdaad beter is om gewoon alles in een tabel te stoppen als je relatief weinig records verwacht. ( kunnen we nu natuurlijk gaan discussieren over wat relatief weinig is )
.....

Dit betekent dat je de weddenschap niet aangaat (ook niet bij relatief veel records) ?

[Renegade]

Op dinsdag 20 maart 2001 13:51 schreef chem het volgende:

[..]

nee, nee, niet alle text in een veld plaatsen...
je opent file x
pak de text, filter de html en andere voor de hand liggende troep eruit
explode op spatie tot array van tekens & woorden
voeg woorden die /geen/ ruis toe als 1 record toe aan de DB, bij herhaling update je het # hits, evt. met factor (bv. onderaan is 0.2, bovenaan 0.8), met filename erbij
je krijgt dus PER WOORD PER FILE een record. Stel je file heeft 10,000 woorden waarvan 3,500 uniek dan heb je dus 3,500 records per file.

maar dat betekent dat je bij ieder record meerdere locaties kunt hebben waar de trefwoorden in voorkomen

snappie? En dat levert een flinke table maar met indeces ben je daar ZO doorheen... evt. kun je dit nog normalizeren: aantal, woord en file over 3 tables splitsen zodat de db errug klein wordt in filesize.

Lijkt me grappig om te proberen, alleen ben ik niet zo bedreven met indices, iemand een enigzins logische verklaring wat dit (/deze dingen?) precies doet (/doen)?

[dusty]

Op dinsdag 20 maart 2001 19:31 schreef sjako het volgende:
Dit betekent dat je de weddenschap niet aangaat (ook niet bij relatief veel records) ?

Dat zei ik helemaal niet

Ik gaf alleen aan als het weinig records zijn dat je toch echt beter op de 3-tabellen manier kunt doen. ( Voordat iemand het op mijn manier gaat maken voor slechts 500 files )

Ik ben wel gemeen.. maar niet ZO gemeen

[Renegade]

Op woensdag 21 maart 2001 08:03 schreef dusty het volgende:

[..]

Ik ben wel gemeen.. maar niet ZO gemeen

Mwoah......

[chem]

Op dinsdag 20 maart 2001 23:11 schreef Renegade het volgende:

[..]

maar dat betekent dat je bij ieder record meerdere locaties kunt hebben waar de trefwoorden in voorkomen
[..]

Lijkt me grappig om te proberen, alleen ben ik niet zo bedreven met indices, iemand een enigzins logische verklaring wat dit (/deze dingen?) precies doet (/doen)?

indeces maak je in mysql als volgt:
create index my_name on table (column1, column2, ...)

je kan ook 1 column opgeven. Als je vv. in je where clause exact aan de index voldoet, zal hij niet in de database (!) gaan zoeken maar in de veel kleinere index naar de locatie van de records.

je kunt erachter komen of de index goed werkt met explain select ... cq. 'explain' voor je query zetten.

Verder: je zit dan met 1 record per woord per file. Komt het woord in meerdere files voor, dan krijg je meerdere records.
Dit kan je aanpassen uiteraard met 1 table van woorden, 1 table van files en 1 kruistabel.

have fun

[Renegade]

Hmmm, ik ga maar weer eens wat verder aan het prutsen, es ff kijken wat eruit komt, in de tussentijd zijn verdere suggesties/opmerkingen natuurlijk hartelijk welkom. Tot zover wil ik iedereen voor de hulp bedanken, en ik zal tussentijds hier wel de updates op de zoekmachine plaatsen, om jullie mening weer eens te pollen.

[Renegade]

Geen verdere suggesties?