[php/mysql] opzet van een vergelijkingssite

[RSD]

Ik vroeg me af hoe een vergelijkingssite zoals kelkoo.nl bijvoorbeeld nu hun database ongeveer inrichten. Gebeurt het vergelijken allemaal handmatig of gebeurt het gedeeltelijk handmatig en gedeeltelijk via slimme algoritmen. Immers sommige produkten die hetzelfde zijn hebben soms net een andere benaming of een kenmerk staat bijvoorbeeld omgedraaid in de titel. Hoe gaat dit in zijn werk. kan ik hier ergens meer over lezen en dan met name hoe ik zo een site kan gaan scripten. Ik heb namelijk geen idee.

[Gonadan]

Wat bedoel je precies?
Kan je een voorbeeld geven van de producten die je bedoelt?

Ik begrijp niet helemaal wat je probleem is.
Je zegt dat je geen idee hebt, klopt het dan dat je ook nog geen probleem hebt?
Wij gaan namelijk niet een database voor jou ontwerpen, dus iets meer info graag

[RSD]

Ik vroeg me af hoe zo een site te werk gaat. De database moet immers gevuld worden. Er komen feeds binnen van winkels. De opmaak van deze feeds worden bepaald door de vergelijker. De vergelijker heeft dus allemaal verschillende lijstjes van winkels. Nu bevatten sommige winkels hetzelfde produkt, alleen is de omschrijving net iets anders.

Bijv: Philips cd+rw 20x20 (winkel 1)
Philips 20x20 cd+rw (winkel 2)

Gebeuren dit soort vergelijkings zaken handmatig of niet? En zo nee, hoe dan wel. Daarnaast ben ik nieuwsgrierig hoe een database eruit zou kunnen komen te zien. Dus voor elke winkel een aparte database of elke winkel een aparte tabel of ... ?

Daarnaast hebben bepaalde product groepen ook weer verschillende eigenschappen, hoe gaat dat in zijn werk.

[ Voor 8% gewijzigd door RSD op 01-06-2006 15:07 ]

[Gonadan]

Ik gok dat ze uit de beschrijving alle 'woorden' pakken en dan kijken hoeveel procent er overeen komt.

Qua tabellen zou ik (globaal) het volgende doen:
- tabel met winkels
- tabel met artikelen met FK naar de winkel en FK naar categorieën

[CH4OS]

Gonadan schreef op donderdag 01 juni 2006 @ 15:07:
Ik gok dat ze uit de beschrijving alle 'woorden' pakken en dan kijken hoeveel procent er overeen komt.

Qua tabellen zou ik (globaal) het volgende doen:
- tabel met winkels
- tabel met artikelen met FK naar de winkel en FK naar categorieën

Aannemend dat je de categorieën ook in een aparte tabel hebt?

[Gonadan]

GJ-tje schreef op donderdag 01 juni 2006 @ 15:21:
[...]
Aannemend dat je de categorieën ook in een aparte tabel hebt?

lol ja uiteraard. (anders kan het ook geen FK zijn )
ik zou eerst inventariseren wat ik allemaal wil opslaan en dan eens flink normaliseren met een grote pot koffie ernaast, zoals het hoort

[ Voor 6% gewijzigd door Gonadan op 01-06-2006 15:22 ]

[Janoz]

Het lijkt me dat het mergen van twee producten een core functionaliteit van je beheer tool zal zijn. Hoe slim je alles ook maakt, er zullen er altijd meerderen door de mazen raken. De beheerder zou gewoon snel 2 producten aan elkaar moeten kunnen knopen als zijnde dezelfde.

[mitalp]

Die overzichten zijn te koop; je neemt een abonnement op een 'prijzendatabase', hier staan ook alle categorieen en specs van de betreffende producten in.
De truc is dus niet zozeer dat je aan de informatie weet te komen, maar dat je er voor zorgt dat mensen via jouw vergelijkingssite doorklikken naar andere sites.

Overigens, als je het handig aanpakt en een beetje meetelt, dan hoef je natuurlijk niet te betalen voor die gegevens. In dat geval is een winkel (in wat voor vorm dan ook) maar wat blij als hij met zijn/haar assortiment op jouw site mag staan...

[ Voor 34% gewijzigd door mitalp op 01-06-2006 16:22 ]

[RSD]

Ik heb eens gezocht op foreign keys en mysql, maar ik kom bijzonder weinig tegen.

[CH4OS]

Gonadan schreef op donderdag 01 juni 2006 @ 15:22:
lol ja uiteraard. (anders kan het ook geen FK zijn )

Oh jawel hoor, je kan meerdere PK's en FK's tussen 2 tabellen aanleggen... En anders kan je nog met joins gaan werken... Alhoewel dat wel minder betrouwbaar is natuurlijk...

RSD schreef op donderdag 01 juni 2006 @ 15:26:
Ik heb eens gezocht op foreign keys en mysql, maar ik kom bijzonder weinig tegen.

[search=foreign key mysql]
[google=foreign key mysql]
[search=fk mysql]
[google=fk mysql]
En de docs van MySQL zelf...

Lijkt me genoeg over te vinden dus...

[ Voor 39% gewijzigd door CH4OS op 01-06-2006 15:32 ]

[RSD]

Ik las het zojust al. Een FK is gewoon een id die naar een andere tabel verwijst, alleen bij het aanmaken van je tabel hoef je niet aan te geven dat het een foreign key is.

[CH4OS]

RSD schreef op donderdag 01 juni 2006 @ 15:29:
Ik las het zojust al. Een FK is gewoon een id die naar een andere tabel verwijst, alleen bij het aanmaken van je tabel hoef je niet aan te geven dat het een foreign key is.

Bij het aanmaken van een tabel in een database moet je dat al aangeven...
Vergeet trouwens niet dat bij MySQL je DB type InnoDB moet zijn als je met FK's wilt werken...

[ Voor 8% gewijzigd door CH4OS op 01-06-2006 15:34 ]

[Gonadan]

GJ-tje schreef op donderdag 01 juni 2006 @ 15:27:
[...]
Oh jawel hoor, je kan meerdere PK's en FK's tussen 2 tabellen aanleggen... En anders kan je nog met joins gaan werken... Alhoewel dat wel minder betrouwbaar is natuurlijk...

Um, een FK wijst altijd naar een andere tabel.
Daarom zal die categorie dus in een andere tabel moeten zitten.
Of dacht je echt dat ik bedoelde dat die in de tabel van de winkel zat?

GJ-tje schreef op donderdag 01 juni 2006 @ 15:33:
[...]
Bij het aanmaken van een tabel in een database moet je dat al aangeven...
Vergeet trouwens niet dat bij MySQL je DB type InnoDB moet zijn als je met FK's wilt werken...

Dan krijg je indices, en die zijn vrij handig als je db groot wordt

[CH4OS]

Gonadan schreef op donderdag 01 juni 2006 @ 15:36:
Um, een FK wijst altijd naar een andere tabel.
Daarom zal die categorie dus in een andere tabel moeten zitten.
Of dacht je echt dat ik bedoelde dat die in de tabel van de winkel zat?

Ik dacht dat je daar eerst op doelde ja...

Dan krijg je indices, en die zijn vrij handig als je db groot wordt

Voor zover ik heb na kunnen gaan en voor zover ik weet, moet je bij het aanleggen van je FK's in de DB al aangeven dat veld.tabel eigenlijk een FK is naar veld2.tabel2

[Gonadan]

GJ-tje schreef op donderdag 01 juni 2006 @ 15:45:
[...]
Ik dacht dat je daar eerst op doelde ja...
[...]
Voor zover ik heb na kunnen gaan en voor zover ik weet, moet je bij het aanleggen van je FK's in de DB al aangeven dat veld.tabel eigenlijk een FK is naar veld2.tabel2

Jep

SQL:

create table artikel (
id int autoincrement,
naam varchar(40) not null,
winkel_id int not null,
PRIMARY KEY (id),
FOREIGN KEY(winkel_id) REFERENCES winkel(id) )

of iets dergelijks

[RSD]

Dit is dus alleen mogelijk bij InnoDB

[Janoz]

En bij alle andere fatsoenlijke database systemen anders dan mysql


---

Mijn opmerking sloeg vooral op het 'enkel voor innoDB'. Dat klinkt een beetje alsof het speciaal is dat het voor InnoDB geldt. Feit blijft dat het eerder speciaal is dat alle andere mysql tabeltypen geen foreign keys ondersteunen.

[ Voor 64% gewijzigd door Janoz op 01-06-2006 19:20 ]

[RSD]

Niet zo positief over mysql dus? Wat is dan wel een goed database systeem voor zoiets? En zijn daar ook boeken over te krijgen?

[Gonadan]

mySQL is een prima database.
Volgens mij gebruikt got hem ook

[RSD]

Maar dan wel de InnoDb versie zeg maar.

[CH4OS]

RSD schreef op zaterdag 03 juni 2006 @ 12:00:
Maar dan wel de InnoDb versie zeg maar.

InnoDB zit standaard in elke MySQL versie vanaf ergens in de 4.x serie dacht ik... Bij het aanmaken van je tabel moet je opgeven dat het type InnoDB is...