Portfolio met accent op semantiek, niet op product

[Verwijderd]

Ik ben aan het nadenken over het databaseontwerp van een portfoliosite. De typische onderverdeling fotografie, film, druk,... is niet slecht, maar het lijkt me leuker om de nadruk op het semantische te leggen: sfeerproducten, industrie, interieur,... Dat maakt het er niet echt makkelijker op, want bij de 'categorie' industrie kunnen dus afbeeldingen, videootjes en voorbeeldpdf'jes voor druk staan. Trouwens, ik schrijf categorie tussen aanhalingstekens omdat ik vermoed dat het werken met sleutelwoorden of tags hier beter zal werken.

Maar omdat deze enkele visie wat weinig is om meteen aan het ontwerpen te slaan, graag jullie mening. Alvast bedankt.

[cspare]

Ik snap niet helemaal waarover je onze mening wil hebben. Over hoe je het beste een onderverdeling kan maken? (lijkt me afhankelijk van de klant), of je daarbij het beste tags/sleutelwoorden kunt gebruiken? of over hoe je het beste je database kan opzetten?

[Verwijderd]

Het type onderverdeling ligt vast: de eigenlijk producten (foto, video, tekst,...) worden niet in die onderverdeling aangeboden, maar een sfeervolle foto hoort bij dezelfde categorie als een sfeervolle video. Een mogelijke categorie is dan ook 'sfeerproducten'. Een parallelle categorie kan bijvoorbeeld 'natuur' zijn. En 'industrie' kan ook.

Nu kan het zijn dat een foto zowel bij 'natuur' als 'sfeer' hoort. Wanneer de gebruiker op de portfoliosite dan voor de optie 'natuur' kiest, moet hij die bewuste foto te zien krijgen, samen met een heleboel andere natuurfoto's. Maar als hij voor 'sfeer' kiest, zit diezelfde foto ook tussen de sfeerfoto's.

Ik hoop dat dit een beetje duidelijker is als mijn eerste, wazige post.

[Creepy]

Maar waar wil je nu onze mening over hebben? Of moeten wij een DB opzet voor je gaan uitdenken?

[Verwijderd]

Iep, ik ben niet goed wakker, denk ik. Natuurlijk verwacht ik niet dat jullie het voor me uitdenken.

Ik dacht aan dit:

code:

db_werk
-------
* id (primaire sleutel)
* titel
* beschrijving
* bron (link naar pdf-, jpg-, flv-bestand)
* datum

db_categorie
------------
* id
* categorie_naam

db_werk_categorie
-----------------
* werk_id
* categorie_id

Dit ontwerp impliceert dat er een oneindig aantal categorieën kunnen zijn, en dat eventuele naamswijzigingen ervan snel zijn door te voeren.

Zie ik iets over het hoofd, zo?

[ Voor 19% gewijzigd door Verwijderd op 08-05-2007 12:01 ]

[cspare]

Bij het maken van een (database) ontwerp is het het belangrijkste om te kijken of je alle eisen (requirements) kan afdekken. Gezien je er maar twee hebt gegeven en ik niet voor jou kan bepalen in hoeverre deze requirements vast liggen of hoe waarschijnlijk het is dat er meer bij komen, is het dan ook moeilijk om hier een mening over te geven.
In principe is een ontwerp nooit goed of fout, maar ik denk dat je met dit model wel een eind komt.

[MSalters]

Categorieën in je eerste interpretatie zijn exclusief; in je tweede niet. Misschien kun je beter de Web 2.0 hype term gebruiken; "tag". In dit geval is die inderdaad beter op z'n plek. Ik denk dat je geen lijst met tags nodig hebt, maar normalisatie vraagt er eigenlijk wel om.

[Verwijderd]

Enorm bedankt. Nogmaals excuses voor de ietwat wazige posts, maar ik ben er nu wel uit. Ik heb categorieën gewijzigd in labels (tags, dus), en het datumveld van portfolio naar db_werk naar db_werk_label verplaatst. Zo kan iets ouds toch nog van een nieuw label voorzien, en dan beschouw ik het eigenlijk ook als een beetje nieuw. Dus de datum van toevoeging is niet inherent aan het werk, maar aan de relatie werk-label.

[ Voor 12% gewijzigd door Verwijderd op 10-05-2007 10:17 ]

[Dentist]

Verwijderd schreef op donderdag 10 mei 2007 @ 10:16:
Enorm bedankt. Nogmaals excuses voor de ietwat wazige posts, maar ik ben er nu wel uit. Ik heb categorieën gewijzigd in labels (tags, dus), en het datumveld van portfolio naar db_werk naar db_werk_label verplaatst. Zo kan iets ouds toch nog van een nieuw label voorzien, en dan beschouw ik het eigenlijk ook als een beetje nieuw. Dus de datum van toevoeging is niet inherent aan het werk, maar aan de relatie werk-label.

kijk eens op www.ted.com voor een implementatie van wat je volgens mij in je hoofd hebt. datumveld zou ik overigens zowel in db_werk als in db_werk_label doen. Op die manier kan je een 'last updated tag' naar voren schuiven, terwijl de publicatiedatum niet verandert. Lijkt me wel zo netjes.

[ Voor 21% gewijzigd door Dentist op 10-05-2007 18:08 ]