[Access] Database voor beheer muziekcollectie

Pagina: 1
Acties:

  • Zenyatta
  • Registratie: Oktober 2006
  • Laatst online: 13:21
Om mijn vrije tijd (die schaarser is dan ik zou willen) op een leuke manier te vullen die me niet te veel geld kost, ben ik begonnen met het maken van een database in Access voor het beheer van mijn muziekcollectie.

Met de database wil ik enerzijds mijn fysieke muziekcollectie bijhouden en anderzijds de digitale collectie bijhouden en corrigeren/verbeteren waar nodig. Daarbij hoort ook dat ik vanuit Access de ID3-tags beheer (uitlezen en schrijven) en dat ik de bestandsnamen vanuit de database kan corrigeren.

Ook wil ik hier direct mijn eigen Wikipedia-achtige functionaliteit in bouwen om interessante informatie over artiesten, albums of tracks op te slaan.

En de muziek dan uiteraard ook vanuit de database afspelen en bijhouden wat ik afgespeeld heb, met koppeling naar Last.fm.

Dat alles uiteraard met een moderne UI die in gebruik lijkt op een mix van Spotify, Plex, Netflix etc. Je kunt 'on the go' schakelen tussen een donker en een licht kleurenthema en wellicht later ook je eigen kleurenthema kiezen.

Mijn vraag:

Is er hier op het forum interesse om dit bouwproces te volgen? Zijn er Tweakers die de database uiteindelijk zelf zouden willen gebruiken? Indien er interesse is, kan ik zo af en toe eens iets delen over de voortgang van de bouw. Wellicht hebben jullie dan ook tips en tops vanuit het perspectief van een gebruiker. Ik wil er prima over delen, maar alleen als er geïnteresseerden zijn.

The answer is 42.


  • g0tanks
  • Registratie: Oktober 2008
  • Laatst online: 03-07 20:15

g0tanks

Moderator CSA
Eerlijk gezegd klinkt dit als iets wat je tegenwoordig vrij snel kunt vibecoden. Met Claude Code heb je waarschijnlijk binnen een avond al een werkende MVP met moderne UI. Voor database zou ik eerder kijken naar SQLite of PostgreSQL omdat die beter aansluiten bij moderne frameworks zoals React + Python of Node.js.

Ultrawide gaming setup: AMD Ryzen 7 2700X | NVIDIA GeForce RTX 2080 | Dell Alienware AW3418DW


  • Jester-NL
  • Registratie: Januari 2003
  • Niet online

Jester-NL

... pakt een botte bijl

Pfff...
Als ik het goed lees, wil je dus een (uitgebreide) muziekspeler bouwen in Access. Moedig.
Ikzelf zou het niet doen op basis van Access, omdat ik het idee heb dat je op heel veel plekken opnieuw het wiel gaat moeten uitvinden, en met name bij:
  • Het beheren van je ID3-tags
  • Je Last.fm-plugin
Persoonlijk zou ik eerder kiezen voor het maken van een eigen skin rond een bestaande mediaspeler als Foobar (in combinatie met bestaande plugins).
Ik ben op zich wel benieuwd naar wat je gaat bouwen... maar ik denk dat het de neiging zal krijgen om nogal topzwaar te worden.
Hoe dan ook, succes!

The sky above the port was the color of television, turned to a dead channel
me @ last.fm


  • Zenyatta
  • Registratie: Oktober 2006
  • Laatst online: 13:21
Dank voor jullie reacties.

Ik begrijp de opmerkingen over de keuze voor Access. Als ik vandaag vanaf nul een applicatie zou ontwerpen met als doel een moderne desktop- of webapplicatie te bouwen, dan zou ik waarschijnlijk ook kijken naar zaken als SQLite/PostgreSQL in combinatie met een modern framework.

Voor mij is dit project echter niet alleen een eindproduct, maar ook een hobbyproject waarin het ontwerp, de architectuur en het bouwen zelf een belangrijk onderdeel van het plezier vormen. Bovendien draait er inmiddels al behoorlijk wat functionaliteit, waardoor een volledige herstart op een ander platform niet direct voor de hand ligt.

De opmerking dat ik op bepaalde punten opnieuw het wiel aan het uitvinden ben, herken ik zeker. Dingen als tagbeheer, artworkbeheer en eventuele externe koppelingen zijn problemen die bestaande spelers al lang geleden hebben opgelost. Tegelijkertijd is het juist interessant om te onderzoeken hoe ver ik dat binnen mijn eigen architectuur kan brengen.

Wat misschien nog niet helemaal duidelijk uit mijn oorspronkelijke bericht naar voren kwam, is dat het project niet primair bedoeld is als mediaspeler. Het is eerder een systeem voor het beheren van mijn volledige muziekcollectie, waarbij zowel digitale bestanden als fysieke media een rol spelen.

Een belangrijk uitgangspunt is bijvoorbeeld dat een album meerdere fysieke dragers kan hebben (cd, vinyl, cassette, enzovoort), terwijl dezelfde release ook gekoppeld kan zijn aan digitale bestanden. Dat aspect van collectiebeheer zie ik bij veel bestaande mediaspelers slechts beperkt terug. Die zijn logischerwijs vooral gericht op het afspelen en organiseren van digitale muziekbestanden.

Juist de combinatie van collectiebeheer, metadata, artwork, fysieke uitgaven en digitale bestanden maakt dit project voor mij interessant. De afspeelfunctie is uiteindelijk wel gewenst, maar staat momenteel niet centraal in de ontwikkeling.

Ik ben me ervan bewust dat Access niet de meest voor de hand liggende keuze is voor een project als dit, maar juist dat maakt het voor mij een leuke technische uitdaging. Ik ben vooral benieuwd naar ideeën, kritiekpunten en valkuilen die anderen zien, ongeacht het platform waarop het gebouwd wordt.

In ieder geval bedankt voor het meedenken. Dit is wel het type feedback wat helpt verder denken over mijn project. Wellicht dat als dit draait, ik nog eens verder kijk hoe ik het via SQLight of vergelijkbaar anders op kan zetten of migreren.

The answer is 42.


  • dixet
  • Registratie: Februari 2010
  • Laatst online: 12:31
Zenyatta schreef op zondag 7 juni 2026 @ 11:25:
Voor mij is dit project echter niet alleen een eindproduct, maar ook een hobbyproject waarin het ontwerp, de architectuur en het bouwen zelf een belangrijk onderdeel van het plezier vormen. Bovendien draait er inmiddels al behoorlijk wat functionaliteit, waardoor een volledige herstart op een ander platform niet direct voor de hand ligt.
Als architectuur een belangrijke afweging is ben ik wel benieuwd naar de beweegredenen om voor MS Access te kiezen...

Inhoudelijk heb ik niet zoveel toe te voegen, op één belangrijke architectuurkeuze na. MS Access is database en user-interface in 1 oplossing. Als je ooit zou willen migeren is het goed om nu al zoveel mogelijk in gescheiden lagen te werken: maak in ieder geval een MS Access bestand als "data" laag, met dus alleen de databasetabellen. Maak daar bovenop een apart MS Acces bestand met de user interface. En bij voorkeur zorg je ervoor dat je data-access altijd via queries loopt, niet rechtstreeks vanaf de UI naar de database. Met die drie lagen maak je het jezelf in de toekomst een stuk makkelijker om database of user interface te migreren naar een volwassener platform.

En als een afspeelfunctie uiteindelijk wel gewenst is, denk dan ook na hoe je toegang van buitenhuis wilt regelen (zoals het streamen van je eigen muziek naar je auto). Nu misschien nog geen requirement, maar ik ken hobby-projecten. Voor je het weet wordt je wensenlijstje groter ;)

  • Zenyatta
  • Registratie: Oktober 2006
  • Laatst online: 13:21
dixet schreef op zondag 7 juni 2026 @ 16:04:
[...]

Als architectuur een belangrijke afweging is ben ik wel benieuwd naar de beweegredenen om voor MS Access te kiezen...

Inhoudelijk heb ik niet zoveel toe te voegen, op één belangrijke architectuurkeuze na. MS Access is database en user-interface in 1 oplossing. Als je ooit zou willen migeren is het goed om nu al zoveel mogelijk in gescheiden lagen te werken: maak in ieder geval een MS Access bestand als "data" laag, met dus alleen de databasetabellen. Maak daar bovenop een apart MS Acces bestand met de user interface. En bij voorkeur zorg je ervoor dat je data-access altijd via queries loopt, niet rechtstreeks vanaf de UI naar de database. Met die drie lagen maak je het jezelf in de toekomst een stuk makkelijker om database of user interface te migreren naar een volwassener platform.

En als een afspeelfunctie uiteindelijk wel gewenst is, denk dan ook na hoe je toegang van buitenhuis wilt regelen (zoals het streamen van je eigen muziek naar je auto). Nu misschien nog geen requirement, maar ik ken hobby-projecten. Voor je het weet wordt je wensenlijstje groter ;)
Dank voor de tip.

De logische scheiding tussen data, gebruikersinterface en functionaliteit probeer ik inderdaad zoveel mogelijk aan te houden. Formulieren, modules en onderdelen zoals scanners, browsers en resolvers zijn bewust gescheiden opgezet zodat de code beheersbaar blijft naarmate het project groeit.

Een fysieke scheiding tussen frontend en backend heb ik op dit moment nog niet. Alles zit momenteel nog in één Access-bestand. Dat is deels historisch gegroeid en deels omdat het project voorlopig nog door één gebruiker gebruikt wordt.

Ik zie echter wel de voordelen van een frontend/backend-opzet, ook binnen Access zelf. Niet zozeer met het oog op een migratie naar een ander platform, maar vooral voor onderhoud, versiebeheer, eventuele distributie en eventuele toekomstige uitbreiding. Het staat daarom zeker op mijn radar, al ligt de focus momenteel nog vooral op het verder uitbouwen van de functionaliteit.

Wat betreft afspelen en streaming: dat soort ideeën probeer ik bewust nog even buiten scope te houden. De kern van het project ligt momenteel meer bij collectiebeheer, metadata, artwork en de relatie tussen fysieke en digitale muziekdragers. Plus, ik heb de muziek op de NAS en heb al andere methoden om daar vandaan in bijvoorbeeld de auto af te spelen. Maar ik moet toegeven dat hobbyprojecten de neiging hebben om steeds nieuwe ideeën aan te trekken. :)

En dat ik Access gebruik is vooral ontstaan uit het feit dat ik Access al redelijk ken én dat ik geinspireerd ben door een familielid die Access al jaren gebruikt om zijn video- en fotocollectie te beheren. Ik dacht: dat kan ik ook voor mijn muziek... O-)

[ Voor 4% gewijzigd door Zenyatta op 08-06-2026 23:09 ]

The answer is 42.

Pagina: 1