[PHP/MySQL]dbase ontwerp vraagje

[nikao]

ik loop al een tijdje rond met het idee om een website te maken als IMDB maar dan voor CD's ..

nu zat ik gister daar weer over te denken maar liep al vrij snel tegen wat dbase ontwerp probleempjes aan.

Ik wil dan uiteraard veel info van de cd opslaan. waaronder de deelnemende muzikanten en wat voor instrument ze bespelen. Maar.. dit hoeft natuurlijk niet altijd hetzelfde te zijn.

eerst dacht ik ik maak een tabel met cd's en een tabel met muzikanten.
Met een kolom muzikant id bij de cd waardoor ik weet welke muzikanten er op meegewerkt hebben. Maar nu kan het natuurlijk wel voorkomen dat 1 muzikant op verschillende cd's verschillende instrumenten heeft bespeeld.
Nu zou ik dat wel kunnen oplossen door de muzikant dan 2x als apparte muzikant te behandelen, maar dan sla ik een hoop info dubbel op.
Dit lijkt me handiger kunnen.

iemand ideeën hierover?

[gorgi_19]

Tabel CD
CDid
...

Tabel muzikanten
MuzikantID
..

Tabel Koppeltabel
CDid
MuzikantID

Zo dus?

[drm]

Je zou eens na kunnen denken om eerst een datamodel uit te werken, waarbij je bepaalt wat de verschillende entiteiten zijn (muzikant, muziekinstrument, cd, cdtrack, etc...) en wat de relaties daartussen zijn. Beschrijf die relaties dan ook zo van "1 cd heeft meerdere tracks". Vervolgens kun je dan met dat model aan de slag om dat te implementeren in een database.

Weet je uberhaupt hoe je in een database n:m (veel op veel/"meerdere muzikanten op meerdere cd's")-relaties gerepresenteerd worden?

[nikao]

gorgi_19 schreef op 25 February 2003 @ 08:13:
Tabel CD
CDid
...

Tabel muzikanten
MuzikantID
..

Tabel Koppeltabel
CDid
MuzikantID

Zo dus?

ja dat zei ik dus .. maar dan ga je dus muzikanten info dubbel opslaan in het geval ze op de ene cd een andere bijdrage leverden dan op de andere?.. (muziek instrumenten of producer..lyrics..etc)

[gorgi_19]

nikao schreef op 25 February 2003 @ 10:16:
[...]


ja dat zei ik dus .. maar dan ga je dus muzikanten info dubbel opslaan in het geval ze op de ene cd een andere bijdrage leverden dan op de andere?.. (muziek instrumenten of producer..lyrics..etc)

Je kan ze dubbel opslaan. Je kan hier ook een koppeltabel nog tussen zetten.

[nikao]

Weet je uberhaupt hoe je in een database n:m (veel op veel/"meerdere muzikanten op meerdere cd's")-relaties gerepresenteerd worden?

kweet niet zeker dat ik begrijp wat je bedoelt? je kan toch bij de cd tabel een column muzikantID maken of iets dergelijks waar je de id's van de deelnemers opzet gescheiden door | of iets dergelijks.. (of roep ik nu iets heel ranzigs)

[ACM]

nikao schreef op 25 February 2003 @ 10:19:
kweet niet zeker dat ik begrijp wat je bedoelt? je kan toch bij de cd tabel een column muzikantID maken of iets dergelijks waar je de id's van de deelnemers opzet gescheiden door | of iets dergelijks.. (of roep ik nu iets heel ranzigs)

Ja je roept iets heel ranzigs, hoe ga je uitzoeken op welke cd een muzikant allemaal voorkomt?
Met een like query? En hoe verantwoord je dat dan, dat ie bij een paar duizend CD's in je database ongelofelijk traag begint te worden?

Sowieso zijn er geen relaties te leggen met zo'n soort veld.

[nikao]

gorgi_19 schreef op 25 February 2003 @ 10:19:
[...]

Je kan ze dubbel opslaan. Je kan hier ook een koppeltabel nog tussen zetten.

ik bedoel met dubbel opslaan dat ik de muzikanten table veel info wil opslaan ..
mijn probleem is dus hoe ik opsla wat de betreffende persoon voor bijdrage aan de cd heeft geleverd..
als ik dat in de muzikanten tabel wil opslaan.. zal ik 1 persoon meerdere keren moeten opslaan als hij verschillende dingen heeft gedaan

v.b
muzikant A speelt trombone op cd 1 .. maar trompet op cd 2 ..
(of bedenk ik me nu trombone EN sax op cd3) ..

hoe sla ik dit dan fatsoenlijk op?

[gorgi_19]

nikao schreef op 25 February 2003 @ 10:19:
[...]


kweet niet zeker dat ik begrijp wat je bedoelt? je kan toch bij de cd tabel een column muzikantID maken of iets dergelijks waar je de id's van de deelnemers opzet gescheiden door | of iets dergelijks.. (of roep ik nu iets heel ranzigs)

Je roept nu iets heel ranzings ja.. Dat gaat precies in tegen de ideeen van normalisatie.
Stel je moet een ID verwijderen..... Je wilt weten welke cd's een bepaald artiestenID hebben..

/spuit 11

[ Voor 7% gewijzigd door gorgi_19 op 25-02-2003 10:23 ]

[nikao]

ACM schreef op 25 February 2003 @ 10:21:

[...]

Ja je roept iets heel ranzigs, hoe ga je uitzoeken op welke cd een muzikant allemaal voorkomt?
Met een like query? En hoe verantwoord je dat dan, dat ie bij een paar duizend CD's in je database ongelofelijk traag begint te worden?

Sowieso zijn er geen relaties te leggen met zo'n soort veld.

je hebt gelijk.. ik liep alleen de andere kant op te denken..

[riotrick]

nikao schreef op 25 februari 2003 @ 10:19:
[...]


kweet niet zeker dat ik begrijp wat je bedoelt? je kan toch bij de cd tabel een column muzikantID maken of iets dergelijks waar je de id's van de deelnemers opzet gescheiden door | of iets dergelijks.. (of roep ik nu iets heel ranzigs)

Het lijkt me handig als je eerst eens wat gaat lezen over hoe relationele databases werken. Want wat je nu voorstelt is natuurlijk niet echt handig.

Een één-op-meer relatie (1 cd --> meerdere tracks) kan je weergeven door een id van de één entiteit op te nemen in de tabel van de meer entiteit.

Voor een meer-op-meer relatie moet je een koppeltabel gebruiken (Meerdere cd's <--> meerdere muzikanten). Om dit weer te geven moet je een table cd's maken met cd id erin. een tabel muzikanten met muzikant id erin. En een koppeltabel met alleen muzikant-id / cd-id.

Dat is even snel een beetje het idee. Als dit je allemaal niks zegt, dan zou ik toch echt eerst eens even wat gaan lezen.

[nikao]

ok.. dat snap ik.. dacht alleen dat je dan misschien onnodig een tabel extra gebruikte.. maar ik zie nu inderdaad in dat dit nodig is..
maarrr..
dan nu nog de vraag waar en hoe ik de bijdrage van de muzikant aan de cd (of producer, arangeur etc. alle personen) opsla..
misschien beste om dit dan in nog een apparte table te doen? of kan dit door een bijdrage column toe te voegen aan de koppeltabel?

code:

MuzikantID 
cdID 
bijdrage

[ACM]

Je zult idd nog een derde notie eraan toe moeten voegen.
Je zou ook zoiets kunnen doen:

cd = cdid, cdnaam, ...
muzikant = muzikantid, muzikantnaam, ...

track = cdid, tracknummer, muzikantid, tracktitle
Maar dat laatste is in principe een koppeltabel met wat extra informatie, de onderstreepte delen zijn dan de primary keys in dit voorbeeld.

In de simpele koppeltabel voorbeelden kan een muzikant namelijk niet meerdere keren op 1 cd staan, wat juist in de praktijk regelmatig gebeurd
Een nadeel is dat je de boel wel erg redundant opslaat op het moment dat de complete cd van één muzikant is, maar je bewaart iig wel je flexibiliteit en de opslag overhead is doordat je met id's werkt niet zo heel groot.

Je zou zelfs zoiets kunnen doen:
cd = id, naam
muzikant = id, naam
song = id, muzikantid, naam
cdtrack = cdid, songid, tracknummer

Magoed, it's all up to you

[ Voor 46% gewijzigd door ACM op 25-02-2003 10:42 ]

[nikao]

hmm .. maar in je track tabel krijg je toch weer het probeem wat ik in begin had.. dat er meerdere muzikanten aan 1 track werken..
dus je zou inplaats van een koppeltabel cd <-> muzikant er eentje kunnen maken van track<-> muzikant..
dan heb je de cd ook te pakken.. en als je in die koppeltabel nou ook nog opslaat wat voor functie de muzikant had.. heb je gelijk de mogelijkheid dat 1 muzikant op verschillende nummers verschillende dingen doet..

dit lijkt me een beetje wat ik nodig heb.. of zeg ik nu weer ranzige dingen

[drm]

nikao:
hmm .. maar in je track tabel krijg je toch weer het probeem wat ik in begin had.. dat er meerdere muzikanten aan 1 track werken..
dus je zou inplaats van een koppeltabel cd <-> muzikant er eentje kunnen maken van track<-> muzikant..
dan heb je de cd ook te pakken.. en als je in die koppeltabel nou ook nog opslaat wat voor functie de muzikant had.. heb je gelijk de mogelijkheid dat 1 muzikant op verschillende nummers verschillende dingen doet..

dit lijkt me een beetje wat ik nodig heb.. of zeg ik nu weer ranzige dingen

Nee, dat is inderdaad wel ongeveer de beste manier. Je geeft zelf al aan dat de relatie "muzikant-cd" eigenlijk niet direct bestaat, omdat een muzikant op een track moet spelen, wil hij op de CD voorkomen. Dan krijg je dus een indirecte relatie tussen muzikant en cd, namelijk via 'track' en dat is precies wat je aangeeft

Daarnaast kun je eventueel muzikanten (of medewerkers) aan een CD koppelen, als ze niet direct met een track te maken hebben, maar dan heb je het weer over een andere (directe) relatie, namelijk CD-muzikant, waar de relatie niet afhankelijk is van de track. Het feit dat dat weer een andere relatie is, betekent dus ook dat je weer een nieuwe koppeltabel aan kan maken.

edit:

Ik bedenk me trouwens dat een track eigenlijk geen entiteit is, maar een relatie. Dit omdat nummers ook op meerdere CD's voor kunnen komen, en dat 'tracknummer' dan feitelijk een attribuut is van de relatie 'cd-nummer'

[ Voor 9% gewijzigd door drm op 25-02-2003 11:32 ]

[nikao]

kan ik dan niet een koppel tabel muzikant <-> track maken als volgt:

code:

cd_id
Track_id
Medewerker_id
functie

en dan zeggen dat als de track_id leeg is dat de mederker_id en de functie dan voor de hele cd geldt?

verder had ik nog een vraagje:
wat is dbase vriendelijker.
een apparte song tabel maken waar je de song title, lyrics, composer en jaar van composen opslaat
en vervolgens in de track table de song_id zet zodat je nummers die heel vaak gecoverd worden niet dubbel opslaat (zoals autumn leaves, take 5 en summertime en dat soort nummers)

of is het toch handiger om die info in 1 tabel te houden en dan maar voor sommige nummers info dubbel opslaan? (dan hoef je maar 1 tabel aan te spreken)

[nikao]

ok. bedacht me net dat sommige tracks ook vaker uitgebracht worden op verzamel cd's ed..
dus je zou 2 koppeltabellen krijgen lijkt me:

code:

track_id
medewerker_id
functie
recordlabel_id

en

code:

cd_id
track_id
cd (cd 1,2 enz. bij dubbelcd's of boxsets)
track_number

maar wordt dit niet enorm traag?..
bij 1000 cd's met 20 nummers wordt die laatste tabel al 20.000 records groot..
hoeveel records kan een MySQL dbase eigenlijk een beetje lekker aan.

er staan bijvoorbeeld al 1,8miljoen cd's in cddb... kun je nagaan hoeveel records dat zou opleveren..

[gorgi_19]

* gorgi_19 is niet zo onder de indruk van 20.000 records...
Got heeft al meer dan 6 miljoen records, afaik, in sommige tabellen.

[nikao]

gorgi_19 schreef op 25 February 2003 @ 12:57:
* gorgi_19 is niet zo onder de indruk van 20.000 records...
Got heeft al meer dan 6 miljoen records, afaik, in sommige tabellen.

ok dat is mooi.. heb zelf geen ervaring met zulke grote tabellen vandaar dat ik me afvroeg of dat nog wel prima werkbaar is..

[ACM]

gorgi_19 schreef op 25 februari 2003 @ 12:57:
* gorgi_19 is niet zo onder de indruk van 20.000 records...
Got heeft al meer dan 6 miljoen records, afaik, in sommige tabellen.

Toen er nog een searchengine in mysql bij zat was het zelfs over de 20M records, voor de woordid - topicid relaties, tenminste dat staat me bij

Dat is ook alweer meer dan een half jaar geleden.
Sowieso bevat de messages-tabel ondertussen over de 7M records.

[nikao]

ok.. ik heb al hulp gekregen van iemand van GoT die mee gaat werken aan dit project..(/dev/null)
we zijn nu min of meer tot het volgende dbase ontwerp gekomen..
iemand commentaar hierop? (dingen die we niet handig aanpakken.. relaties die niet ok zijn.. enz?)

code:

Performer
---------------------
performer_ID (unique, index, autoincrement)
name
URL
Info

Song
---------------------
Song_id (unique, index, autoincrement)
Lyrics
Date (of composal)

Track
----------------------
Track_id   (unique, index, autoincrement)
Song_id
Duration
Add_info

Contributor
----------------------
Contributor_Id   (unique, index, autoincrement)
Name
Geb. Dat.
url
Bio
Foto
Add_info

Record label
--------------------
Record label id   (unique, index, autoincrement)
Name
url
info

=================
=koppeltabellen:=
=================

Track medewerkers koppeltabel
-------------------------------
Track_id
Medewerker_id
Functie
Record label_id


track-cd koppeltabel
--------------------------------
Track_id
Cd_id
Cd_number
Track_Number

Composer koppeltabel
--------------------------------
Song_id
Composer (Contributor_id of band_id)
Music (true / false)
Lyrics (true / false)

cd - contributor koppeltabel
-------------------------------------
CD_ID
Contributor_ID
Functie
Record_Label_ID

[cybermans]

offtopic:
check is www.cddb.org heb je veel minder nodig cd_id en cddborg_id

swwy zal het niet meer doen

[ Voor 28% gewijzigd door cybermans op 26-02-2003 00:03 ]

[drm]

cybermans:
check is www.cddb.org heb je veel minder nodig cd_id en cddborg_id

offtopic:
vriendelijk verzoek dergelijke replies achterwege te laten. offtopic posts worden hier niet op prijs gesteld.

edit:
ok

[ Voor 3% gewijzigd door drm op 26-02-2003 00:15 ]