Muziekdatabase

[2020Media]

Ik probeer een datatbase te maken voor een soort top 40 site; gewoon een simpele muziek chart dus, het is de bedoeling dat de chart elke week geüpdatet wordt en de chart van de voorgaande week via een dropdown uit de database kan worden gehaald.

De informatie die de tabellen moeten omvatten zijn als volgt: Datum, Positie, Cover plaatje, Artiest, Nummer, Album, Youtube link, vote up down.

Het is alleen gigantisch lang geleden dat ik met mysqpl bezig ben geweest en ben even helemaal de weg kwijt ik had het volgende in gedachten:


Het is dus de bedoeling dat elke datum een nieuwe "chart" bevat votes worden elke week gerest maar dit gebeurt automatisch bij het maken van de nieuwe tabel.

[CrashOverDrive]

Waarom een aparte tabel voor je datums?
Dat kan je imo prima in je charts tabel oplossen.
Eventueel een nummeriek ID toevoegen voor primary key, maar dat moet genoeg zijn.

Artist en song zijn dan weer dingen die ik wel zou normaliseren, en dus in een aparte tabel zou stoppen.
*afhankelijk van de schaal, kan je een tabel songs maken, met daarin velden artist, song, album
of zelfs dieper gaan, en een tabel met artists maken, daarboven een tabel met songs, en ertussenin een tabel met albums die ze aan elkaar koppelt.

Het is allemaal afhankelijk van hoe flexibel jij de boel wilt opzetten

Zelf zou ik dus doen:
#charts // 1 chart per week bijv
chartId
date

#chartSongJoin // Meerdere nummers aan een chart
chartId
songId
position

#albums
albumId
album
coverImage
artistId

#albumSongsJoin // Een nummer kan op meerdere albums verschijnen
albumId
songId

#songs
songId
song
youtubeUrl
votes // (vote up/down is niet iets wat je in je db zet )

#songsArtistsJoin // Nummer kan meerdere artiesten hebben ivm samenwerking
songId
artistId


Ik ben niet meer geheel helder, is tijd voor wat slaap Maar dit moet het zo ongeveer zijn. Ik vindt zelf dat je moet normaliseren waar nodig om dubbele data te voorkomen. Maar als dit voor een hobby-site is, klein van opzet dan zou het weer redelijk overkill kunnen zijn om de db zo in te delen

en je zou dus ook op plekken die "id's" als primery keys kunnen vervangen door bijv een combinatie van artist+nummer. maar ik vindt zelf id's overzichtelijker werken.

[ Voor 5% gewijzigd door CrashOverDrive op 31-05-2011 05:10 ]

[mrFoce]

CrashOverDrive schreef op dinsdag 31 mei 2011 @ 05:05:

#songs
songId
song
youtubeUrl
votes // (vote up/down is niet iets wat je in je db zet )

Ik zou 'votes' in een aparte tabel zetten.

#votes
voteId (ik ben zelf meer fan van vote_id, maar goed, neem je syntax even over)
voteIp (misschien limit van 1 vote per ip per song? Kan je ook vervangen door een accountId als je met accounts gaat werken)
songId (bij welke song hoort deze vote)
vote ( ligt er maar net aan wat je precies wilt. Als het alleen thumps up + down is, zou je hier waarden in kunnen stoppen van -1 en +1 )

[ Voor 4% gewijzigd door mrFoce op 31-05-2011 05:49 ]

[Varienaja]

Een vote is een gebeurtenis met daarin een getal (+1 of -1) en een timestamp (datum+tijd van het moment van stemmen.

Als je deze informatie koppelt met een song ben je eigenlijk al klaar: wanneer je van een bepaalde week de top40 wilt halen koppel je de songs met de votes op een bepaald datumbereik, en sorteer je naar de som van de votes, maximaal 40 records selecteren en klaar.

Met twee tabelletjes is het gepiept.

[MLM]

Waarom wil je de datestamp van een vote?
Extra kolommetje "upvote" en "downvote" in je table, ben je gelijk met 1 tabel klaar

Met de informatie die ik in de TS zie, zou ik niet gelijk voor een genormaliseerde 10 tabel epic-join gaan. We praten hier over 40 rijen in totaal, een key is niet eens noodzakelijk Voor zover ik zie wil de TS de data nadat de datum verstreken is toch al de deur uit doen

[Caelorum]

Ik zie toch echt de wens.voor historie terug in zijn post. Zelf zou ik het ook enigszins normaliseren
. Kijk iig goed.naar welke data je hebt en de relaties daartussen en probeer waar handig dubbele data te voorkomen.

[mrFoce]

MLM schreef op dinsdag 31 mei 2011 @ 07:35:
Waarom wil je de datestamp van een vote?

Is niet zo lastig om dit te bedenken toch?

'Popular this week' of iets in die trant is mogelijk als je de timestamp bijhoud van de 'votes'.

[Verwijderd]

Ik zou zoiets doen.



Ik ben het eens met wat CrashOverdrive al zei: je hoeft je datums niet in een aparte tabel te bewaren. Als je een tabel met votes hebt en bij elke vote de datum/tijd dan kun je daar gewoon op queryen om week/dag/maand x te selecteren.

[Gomez12]

Verwijderd schreef op vrijdag 03 juni 2011 @ 18:05:
Ik ben het eens met wat CrashOverdrive al zei: je hoeft je datums niet in een aparte tabel te bewaren. Als je een tabel met votes hebt en bij elke vote de datum/tijd dan kun je daar gewoon op queryen om week/dag/maand x te selecteren.

Hangt ervanaf wat je doel is.
Als je simpelweg een overzicht wilt geven van de votes van deze week/maand/jaar dan heb je met enkel vote-datums een kans op gaten (bijv als er op donderdag niet gestemd is, dan heb je geen donderdag)
Dan kan je heel erg moeilijk server-side gaan zitten klooien om de gaten op te vullen, of je kan simpelweg 1 extra tabel genereren met daarin alle data van de komende 10 jaar om daar tegenaan te joinen...

[Verwijderd]

Gomez12 schreef op vrijdag 03 juni 2011 @ 18:10:
[...]

Hangt ervanaf wat je doel is.
Als je simpelweg een overzicht wilt geven van de votes van deze week/maand/jaar dan heb je met enkel vote-datums een kans op gaten (bijv als er op donderdag niet gestemd is, dan heb je geen donderdag)
Dan kan je heel erg moeilijk server-side gaan zitten klooien om de gaten op te vullen, of je kan simpelweg 1 extra tabel genereren met daarin alle data van de komende 10 jaar om daar tegenaan te joinen...

Da's een waarheid als een koe.

Het is een afweging die je moet maken. Ik zou zelf geen datums in een database steken waarvan je niet weet of je ze ook echt nodig hebt. Dat beschouw ik als redundante data. In principe is de informatie "op donderdag 4 februari 2011 is er niet gestemd" natuurlijk impliciet aanwezig doordat er geen records zijn voor donderdag 4 februari 2011. Ik zou dus gaten gaan vullen op de server.

Ik denk dat die aanpak voor de TS ook wel handig is. De enige situatie wanneer de TS op de server een 'gat' zou moeten vullen omdat er geen data is, is als er een hele week geen stem is uitgebracht.

EDIT:

Overigens zou je ook moeten weten hoe het stemproces precies verloopt. Je wil natuurlijk niet dat een of andere blije geit 788 keer op Nick en Simon gaat stemmen in je mooie nieuwe top 40 app, dus gebruikersregistratie en iets van een maximaal aantal stemmen per week zou ook niet gek zijn.

[ Voor 11% gewijzigd door Verwijderd op 03-06-2011 19:09 ]