MySQL: advertenties filteren

[Verwijderd]

Hallo :]

Ik ben bezig met een marktplaatsachtige website en probeer op die site ervoor te zorgen dat advertenties gefilterd kunnen worden, net als op Tweakers' Pricewatch.
Als iemand zijn mobiel te koop op de site zet in de categorie mobieltjes, kan hij ervoor kiezen het aantal megapixels, de grootte van het beeldscherm, et cetera in te vullen, zodat een advertentie beter gevonden kan worden.

Hoe gaat de database er dan uit zien?
Het probleem zit hem vooral hierin, dat sommige waarden een INT moeten zijn (volume, gewicht) en andere weer VARCHAR (merknamen, et cetera). Hoe heeft Tweakers dat gedaan?

Ik heb al een opzetje:

Tabel filter_advertentie verbindt de advertenties met filters, en krijgt de waarde van een filter mee - bijvoorbeeld 3 (Liter).
Tabel filters heeft een naam van een filter - bijvoorbeeld "inhoud" - en een type, zodat je kunt weten wat voor soort filter het is (INT of VARCHAR). Daarnaast is er een "eenheid", bijvoorbeeld Liter. Nu blijft dus de vraag, hoe selecteer je de advertenties met filter "inhoud" 3 tot 5 Liter als "filter_value" een VARCHAR is?

[Tarilo]

Ik snap niet helemaal hoe je dit precies voor je ziet. Als ik het goed lees wil je een site bouwen waar mensen hun spullen te koop kunnen zetten. Kun je ook gevraagd advertenties plaatsen? Vervolgens wil je dat er advertenties op je site komen en die extra advertentie moeten gefilterd worden, zodat ze passen bij de advertentie van die gebruiker?

Zijn die extra advertentie, dan andere advertenties dan die van de gebruikers of dezelfde?

Ik zou 1 tabel hebben waar alle advertenties van de gebruikers in staan, met alle specificaties. Vervolgens kan je in die tabel dan gaan zoeken naar soortgelijke advertenties, of in een andere tabel met advertenties waar ook de specificaties in staan.

De filters die je toe moet passen zijn dan toch gewoon de specificatie van de advertentie van de gebruiker, met een bereik daaromheen, lijkt mij.

Volgens mij denk je nu namelijk te moeilijk, maar het kan goed zijn dat ik niet snap hoe je het precies wilt hebben.

Om het zoeken in filters makkelijker te maken, zou ik zoveel mogelijk filters het type INT meegeven. Ik weet niet welke producten allemaal aangeboden gaan worden, maar in het geval van elektronica kom je daar een heel eind mee. Dingen die dan toch een VARCHAR nodig hebben kan je natuurlijk ook gewoon als INT in je advertentie tabel zetten en dan in een andere tabel zetten welke INT waarde wat betekent. Dan kan je snel door je advertenties zoeken en heb je toch dat merknamen enz. opgeslagen kunnen worden.

[Verwijderd]

Hoi Laurens,

Je begrijpt me verkeerd, advertenties zijn niets anders dan spullen die te koop worden aangeboden. Oftewel, als iemand iets te koop aanbiedt op die website, geeft hij een titel, een beschrijving en een categorie op. Daarna gaat hij specifieke informatie geven over zijn product, namelijk het aantal megapixels, het gewicht, de snelheid. Met deze specifieke informatie bedoel ik filters.
Kopers zullen naar de categorie gaan waar ze naar benieuwd zijn en filteren uit wat zij zoeken. Als ze zoeken naar een mobieltje met een goede camera filteren ze 'Aantal megapixels' van 3.2 tot 8.0. Of als ze zoeken naar een stofzuiger filteren ze 'Merk' op Nilfisk.

Je komt er dus niet onder uit dat zowel VARCHAR als INT als types gebruikt worden.

[edit]
Een aparte tabel als filter_values zou misschien wel een oplossing kunnen zijn... Altijd een INT plaatsen in de kolom `filter_value` in de tabel `filter_advertentie` en die laten verwijzen naar de tabel `filter_values`.
Maar wordt het daar niet erg ingewikkeld door? Duurt het laden van een pagina met advertenties en filters aan de zijkant dan niet erg lang? En hoe kom ik er snel achter wat de te kiezen waarden van die filters zijn? (bijvoorbeeld merk: Nokia, Samsung. Of aantal megapixels: minimaal 0.3 en maximaal 10)

[ Voor 25% gewijzigd door Verwijderd op 02-12-2009 22:18 ]

[cariolive23]

Wat is "filter" ? Dat is er niet, dat is hier het werkwoord "filteren". Gooi dit dus uit jouw database, jouw database gaat geen werkwoorden bevatten. Wat jij wil opslaan, zijn de eigenschappen van de objecten. En daarbij kun je denken aan het aantal megapixel, het aantal kleuren, etc. etc. Dat heeft niets met filters te maken, tenzij je ook bv. luchtfilters gaat verkopen.

Camera's bevatten de eigenschap "megapixel", een stofzuiger bv. de eigenschap "x" (huishouden is niet mijn ding ), die eigenschappen moet je dus koppelen aan de producten. Vervolgens moeten deze eigenschappen nog een waarde krijgen en ook die kun je in de koppeltabel kwijt.

Maar ga in hemelsnaam niet van die nietszeggende kolomnamen gebruiken, dat zorgt voor heel veel verwarring. En dus geen werkwoorden gebruiken als kolomnaam, een actie is geen statisch ding.

[GrooV]

Categorieen maken, bijvoorbeeld een camera heeft 5 product eigenschappen. Dit is dan voor alle camera's en hier kan je dan op filteren

[Freeaqingme]

Volgens mij zoek jij EAV. Als je weet waar je op moet zoeken zal dat e.e.a. een stuk makkelijker maken

[Wolfboy]

Je hebt hierbij een aantal verschillende opties:
[list]• per product type een nieuwe tabel met daarbij dus een datamodel dat alles direct kan opslaan• meerdere kolommen opslaan in filter_advertentie (e.g. filter_value_int, filter_value_char, etc..)
• per datatype een nieuwe tabel (e.g. filter_advertentie_int, filter_advertentie_char) met een datatype bij filters

Kies maar wat je het makkelijkst vind.
Optie 1 vereist aanpassen van de tabellen bij het toevoegen van een eigenschap
Optie 2 is weer net wat minder efficient kwa opslag maar makkelijker kwa queries
Optie 3 is efficient kwa opslag maar weer lastig met querien

[cariolive23]

Optie 1 vereist aanpassen van de tabellen bij het toevoegen van een eigenschap

Is dus fout, je gaat niet het datamodel aanpassen omdat er toevallig een eigenschap bij komt. Dit is onwerkbaar en zéér foutgevoelig. Dit geeft aan dat je niet goed hebt genormaliseerd.

[Verwijderd]

@cariolive23
Je hebt gelijk, de termen die ik heb gebruikt kloppen niet en zorgen voor verwarring. De term filter moet in deze context gebruikt worden voor de databasestructuur zelf, die filteren op eigenschappen van een product mogelijk maakt, en is dus niet synoniem aan eigenschap. Goed dat je het zegt!

@freakingme
Leuk dat je weet dat je de naam van zo'n databasestructuur weet, daar ga ik nu naar kijken. Dank

@Wolfboy
De derde manier is de meest efficiënte, al is hij allicht slomer. Daarnaast zou er een tabel bij moeten komen met de naam `eigenschapswaarden`, die ervoor zorgt dat er geen dubbele waarden (zoals merknamen et cetera) in de database komen. Hier komt de manier van @freakingme waarschijnlijk om de hoek kijken, daar moet ik nu eerst maar over lezen.

[cariolive23]

De derde manier is de meest efficiënte, al is hij allicht slomer.

Gebrek aan performance komt vaak van slechte queries, gebrek aan bruikbare indexen, belabberde database configuraties en inefficiente code. Wanneer het datamodel goed is, kan de performance ook goed zijn. Een tabelletje meer of minder heeft op de performance geen/nauwelijks invloed.

Komt bij dat het geen zin heeft om je nu druk te maken over performance, je hebt nog helemaal geen performanceprobleem. Die kun je dus ook niet oplossen.

[Verwijderd]

cariolive23 schreef op donderdag 03 december 2009 @ 16:02:
Wanneer het datamodel goed is, kan de performance ook goed zijn. Een tabelletje meer of minder heeft op de performance geen/nauwelijks invloed.

Zie hier, een wel aardig goed datamodel, vind je niet? Ik heb me niet meer druk gemaakt over een tabel meer bij een datatype, maar ze gewoon in één tabel gestopt, ze zullen toch wel bijna altijd INT of VARCHAR zijn.


O ja, een beschrijving van hierboven is handig:
Elke advertentie staat in een categorie. Eigenschappen van advertenties gelden voor alle advertenties in een categorie. [ik zie dat er eigenlijk nog een tabel bij moet, met een relatie tussen categorieen en eigenschappen]. Elke eigenschap heeft waarden. Elke advertentie heeft waarden bij een eigenschap.

[ Voor 25% gewijzigd door Verwijderd op 03-12-2009 17:29 . Reden: Beschrijving van verbeterd datamodel toegevoegd ]

[Confusion]

Je kan te ver gaan met je normalisatie en de waarden van eigenschappen normaliseren is echt een stap te ver.

Bovendien is het vragen om consistentieproblemen om cirkels in je db model te hebben. Waarom moeten eigenschappen aan een categorie hangen? Heb je echt nooit dezelfde eigenschap in meerdere categorieen?

[ Voor 12% gewijzigd door Confusion op 03-12-2009 17:37 ]

[pedorus]

Waarmee maak je die plaatjes eigenlijk en hoe moeten we de kleuren lezen? Wat ik hier zie is denk ik een schitterend voorbeeld van het zogenaamde Inner Platform Effect, niet geheel toevallig gelinkt vanaf EAV...
Wat is er mis met -al dan niet automatisch gegenereerde- kolommen voor dingen als 'aantal megapixels'?

Overigens heeft T.net wat problemen gehad met de snelheid van de pricewatch, zie hier, en heeft daarom nu een soort eigen in-memory java-database in gebruik. Hoe het achterliggende datamodel eruit ziet weet ik niet, maar als een categorie met 1000-2000 producten problemen geeft, gok ik dat je dat datamodel beter niet als voorbeeld kan nemen (nofi), of je moet mankracht hebben voor een soortgelijke oplossing.

[Verwijderd]

Ok, ik begrijp dat het simpeler moet... Maar hoe moet het dan?

Kolommen als 'aantal megapixels' zijn niet handig voor een website met totaal verschillende soorten categorieën (ik noemde niet voor niets stofzuigers, een eind hierboven ).

Overigens, is het wel overdreven? Dat valt toch wel mee? Misschien moet de tabel categorieën weggedacht worden, die is er alleen maar om te laten zien dat producten in een bepaalde categorie bepaalde eigenschappen wel of niet kunnen hebben.


De plaatjes maak ik met met WWW SQL Designer. Kleurtjes staan voor types: rood is VARCHAR, geel is INT

[pedorus]

Verwijderd schreef op donderdag 03 december 2009 @ 19:26:
Kolommen als 'aantal megapixels' zijn niet handig voor een website met totaal verschillende soorten categorieën (ik noemde niet voor niets stofzuigers, een eind hierboven ).

Ik zou persoonlijk ook nooit tegelijkertijd zoeken binnen stofzuigers en telefoons, dus waarom zouden alle eigenschappen in dezelfde tabel moeten zitten? Je kan dus een model hebben met een hoofdtabel voor dingen als id, locatie, aanbieder, ... en subtabellen voor dingen als 'aantal megapixels', 'inhoud', enz..

[Tarilo]

Ik zou inderdaad per product categorie een aparte tabel maken. Of zoals pedorus zegt, met een hoofd tabel en verschillende sub tabellen.

Ik denk dat je inderdaad te moeilijk denkt. Bedenk gewoon een zo simpel mogelijk model, te simpel voor je idee. Ga daarna kijken of je alles kan wat je wilt en dan kun je dingen gaan uitbreiden enzo, maar niet gelijk te moeilijk denken. Dan zie je door de bomen het bos straks niet meer, terwijl het helemaal niet zo moeilijk hoeft te zijn. Lijkt mij.

[Wolfboy]

pedorus schreef op donderdag 03 december 2009 @ 20:06:
[...]

Ik zou persoonlijk ook nooit tegelijkertijd zoeken binnen stofzuigers en telefoons, dus waarom zouden alle eigenschappen in dezelfde tabel moeten zitten? Je kan dus een model hebben met een hoofdtabel voor dingen als id, locatie, aanbieder, ... en subtabellen voor dingen als 'aantal megapixels', 'inhoud', enz..

Het probleem met zoiets is alleen dat je ofwel een master tabel moet hebben met product en daarna per categorie een eigenschappen tabel, of je raakt al je referentiele integriteit kwijt waardoor je elke tabel die linkt naar een product ook zal moeten hebben per categorie.

[kwaakvaak_v2]

dit lijkt mij juist iets wat je in een product als couchDB wil opslaan omdat je het dan volledig schema-loos kan doen en juist de flexibiliteit van een niet rdbms goed kan gebruiken.

[cariolive23]

kwaakvaak_v2 schreef op donderdag 03 december 2009 @ 23:53:
dit lijkt mij juist iets wat je in een product als couchDB wil opslaan omdat je het dan volledig schema-loos kan doen en juist de flexibiliteit van een niet rdbms goed kan gebruiken.

Goede opmerking, dit is zeker een proof of concept waard.

[Verwijderd]

Waarom niet gebruik maken van apache solr, de facet search kan je hier uitstekend voor gebruiken en zelfs uitbreiden met geo search.

[creator1988]

Waarom sla je niet vanuit de bron database al je objecten plat als in

[TVs] => [indSchermGroterDan70cm] [indKleur]
[Radios] => [indMP3] [indBlabla]

Dan werk je vanuit je website tegen de platgeslagen database aan; en kan je razendsnel querien. Heb je alleen een synclaag nodig