Opgelost Kan deze muziekdatabase efficiënter worden gemaakt?

Dit topic is als opgelost gemarkeerd
Status
Niet open voor verdere reacties.
Dit heb ik van CoPilot
Draai die dan maar de nek om. Normaliseren is het enige dat je moet kennen/kunnen.

In de discussie over predicaten hebben @Aar en @OctaFish mijns inziens beide gelijk. Het is maar waar je voor kiest.
Persoonlijk voel ik meer voor de keuze van @Aar. Als er een predicaat bijkomt wil je niet dat je een (keuzelijst in een) tabel en/of formulier aan moet passen. Zeker niet als de rollen van ontwikkelaar en gebruiker bij verschillende personen berusten.
Een interessante discussie is nog of een track van een album een predicaat krijgt of een single o_O

Je relaties snap ik nog niet allemaal. Als ik kijk in het schema dan kan een muziekbox in een vertrek liggen of op een plank. Zou zomaar kunnen.
Verder ontbreken er wat relaties rond "combi" tabellen.
En wat doet/is tOpbergen?
opbergen.jpg
 
  • Leuk
Waarderingen: Aar
Als er een predicaat bijkomt wil je niet dat je een (keuzelijst in een) tabel en/of formulier aan moet passen. Zeker niet als de rollen van ontwikkelaar en gebruiker bij verschillende personen berusten.
Weer een erg boude stelling. Al was het maar omdat je bij het toevoegen van een predicaat altijd ergens iets moet aanpassen, ofwel in de tabel, ofwel in de keuzelijst :). Daarnaast is het 'dichttimmeren van een keuzelijst' in een tabel beter te beveiligen (d.m.v. een FE-BE) dan waardes toevoegen aan een tabel, waar een gebruiker immers makkelijker bij kan.

Zoals ik al zei: het hangt maar net van het gebruiksdoel van een keuzelijst af hoe je die inricht. Dat kan een Lijst met velden zijn, of een tabel. Waarom denk je dat beide opties aanwezig zijn?
Een tabel maken voor een keuzelijst Aanhef met 3 of 5 opties vind ik behoorlijk overdreven. Zelfs als er weer een 'nieuwe' categorie 'mens' wordt bedacht door iemand, is die daar zo aan toegevoegd.
Heb je het over plaatsnamen, dan is het een heel ander geval. Ik kies dus niet voor altijd de keuzelijsten maken d.m.v. <Lijst met waarden>, maar kijk naar het doel van de keuzelijst, en bepaal aan de hand daarvan wat op dat moment de beste optie is.

Kortom: de enige juiste aanpak lijkt mij: bekijk de situatie, en kies op basis daarvan wat dan de handigste optie is. En dat lijkt mij de juiste manier van ontwerpen. Blind voor één vaste oplossing kiezen, kan nooit de juiste zijn.

Verder ben ik het Peter eens dat de opzet veel te ingewikkeld gemaakt is :). Ik zou deze variant niet willen ruilen voor de mije :D.
 
Tot mijn schrik zie ik, dat ik een verkeerd exemplaar heb gepost. Mijn verontschuldigingen hiervoor. Hierbij het juiste exemplaar,
Volgens mij is er niets mis met het gebruik van CoPilot, vooral niet op de manier waarop ik het hier gebruikt heb. Julitta Korol, schrijfster van het Access 365 Project Book, maakt in haar boek ook gebruik van CoPilot
 

Bijlagen

Je moet nooit ervanuit gaan en nooit meteen doen wat een AI-assistent zegt. Je moet altijd een eigen oordeel hebben of dat advies wel waardevol is. Het is immers ook geen glazen bol.

Verder ben ik benieuwd of je iets met mijn tips kon doen, en of je een recente afbeelding hebt van je structuur ipv een rar die op smartphones niet makkelijk te openen is. Afbeeldingen maken alles makkelijker. 😉
 
Wat nu als een bepaald nummer meerdere keren een bepaald predicaat krijgt?
Het is inderdaad een keer voorgekomen dat dezelfde track twee keer tot alarmschijf werd gekozen: Happy X-mas van John Lennon in 1972 en 1980.

Ik ben meer van de concrete voorbeelden, dan van de abstracte begrippen. Als ik het voorbeeld van Aar goed begrijp, verwijs ik in de koppeltabel twee keer naar het nummer Happy X-Mas. Een keer met de verwijzing naar 1972 en een keer naar 1980.
 
  • Leuk
Waarderingen: Aar
Klopt helemaal. In de koppeltabel verwijs je naar de trackID, het PredicaatID en de datum van het predicaat.
Het predicaatID is hier de koppeling die in deze tabel dus niet uniek is. Dus je kan oneindig veel dezelfde of verschillende predicaten toevoegen aan een bepaalde track.
 
Ik ben meer van de concrete voorbeelden, dan van de abstracte begrippen.
En toch moet je daar wel iets vanaf weten als je databases gaat maken. En dan vertrouwen op tools als AI of CoPilot gaat je dan echt niet helpen. Het gaat er om dat jíj snapt wat je wilt en hoe je dat kan verwezenlijken.
In het geval van muziektracks is het vrij simpel: in die tabel sla je alleen die gegevens op die betrekking hebben op het nummer. Dus de eigenschappen van die nummers. Of een nummer een alarmschijf is of niet, is geen eigenschap van dat nummer. Dat blijkt wel uit het feit dat een nummer vaker alarmschijf kan zijn.

Je doet er dus verstandig om al die velden te verwijderen uit de tabel, en daar een koppeltabel van te maken. En in die koppeltabel dus een veld waarin je de juiste categorie kan kiezen.
 
Dan krijg je zoiets:

Relaties.jpg

En de betreffende velden zet je dan uiteraard over naar de nieuwe tabel(len).
 
Als je de gegevens inderdaad gaat overhalen naar een koppeltabel, dan wil je natuurlijk de gegevens ook op een handige manier kunnen importeren in die tabel. Dat is met de hand eigenlijk niet te doen, al kun je daar uiteraard wel queries voor maken. Ik programmeer dat soort zaken graag, dus in de bijlage vind je een module met daarin een functie die e.e.a. netjes inleest. De tabel tMuziek_Predicaten bevat nu dus de Predicaat gegevens, en de velden in Muziektracks zijn in deze db verwijderd.
 

Bijlagen

Iedereen bedankt voor het meedenken en meehelpen. Ik neem voor het vullen van de muziekdatabase de bijgewerkte versie van Michel als uitgangspunt. Ik ben weer een stuk wijzer geworden. Ik begrijp jullie weerzin tegen het gebruik van AI bij het maken van databases. Als naslag voor gebruikte termen vind ik het een welkome aanvulling; je moet het resultaat echter wel met een kritische blik bekijken. Ik denk dat mijn vraag voldoende beantwoord is, daarom zet ik hem op opgelost.

Met vriendelijke groeten,

Henk
 
  • Leuk
Waarderingen: Aar
Als naslag kun je ook de Help functie van Office pakketen gebruiken; die is doorgaans voldoende (en vermoedelijk sneller te gebruiken. Daarnaast moet ik nog zien dat AI in staat is (of ooit zal zijn) om in jouw hoofd te kijken om te zien welke wensen en eisen jij aan je database stelt. Maar goed, over een paar jaar blijkt vermoedelijk dat wij roependen in de woestijn zijn geweest :).
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan