Simpel database design

[Y0ur1]

Ik hoop dat ik mijn cursusje normaliseren een beetje heb begrepen... Wat ik wil doen: Al mijn albums die ik heb in mp3 in een database(MySQL) proppen. Ik ga dit dan met php uitspugen op een paginatje.
De relatie is dus 1 op veel, waarbij je dus geen koppeltabel hoeft te gebruiken...

mijn database design is als volgt:

code:

tabel artiest:
id
artiest_id
artiest_naam

code:

tabel album:
id
album_id
album_naam
artiest_id

code:

tabel info:
id
info_id
album_id
bitrate
tracks

Is dit ongeveer goed?

[dominic]

Prima hoor jongen

[Feyd-Rautha]

Hoe moeten wij dat nu weten.
Welke gegevens wil je bijhouden, wat is de relatie tot de gegevens, ...

Geef eens wat meer uitleg.

ps: wij zijn geen meesters die zeggen of iets goed is of niet hé, dat moet je zelf zien. We kunnen enkel tips geven

pps: ik snap wel niet direct wat het verschil is tussen bijvoorbeeld: 'id' en 'artiest_id'

[Verwijderd]

tabel info
id
info_id

Waarom twee maal id?

[Y0ur1]

Feyd-Rautha schreef op 19 June 2003 @ 20:01:
Hoe moeten wij dat nu weten.
Welke gegevens wil je bijhouden, wat is de relatie tot de gegevens, ...

Geef eens wat meer uitleg.

ps: wij zijn geen meesters die zeggen of iets goed is of niet hé, dat moet je zelf zien. We kunnen enkel tips geven

pps: ik snap wel niet direct wat het verschil is tussen bijvoorbeeld: 'id' en 'artiest_id'

id is voor iedere unieke record... artiest_id staat voor een id van een artiest, artiest X heeft bijvoorbeeld id 5

[ Voor 3% gewijzigd door Y0ur1 op 19-06-2003 20:02 ]

[gorgi_19]

Een artiest is toch uniek?

Evenals dat een album uniek is.. Je hoeft imho dus niet EN een uniek ID te genereren en er zelf eentje toe te wijzen...

[André]

Maar zo'n simpele database hoef je hier toch niet te laten keuren?

[Verwijderd]

gorgi_19 schreef op 19 juni 2003 @ 20:03:
Een artiest is toch uniek?

Evenals dat een album uniek is.. Je hoeft imho dus niet EN een uniek ID te genereren en er zelf eentje toe te wijzen...

inderdaad, gorgi_19 heeft gelijk. nu doe je het dubbel

[Verwijderd]

Verwijderd schreef op 19 June 2003 @ 20:02:
tabel info
id
info_id

Waarom twee maal id?

Inderdaad, waarom in iedere tabel 2 id's?

/Edit: een beetje laat.....

[ Voor 10% gewijzigd door Verwijderd op 19-06-2003 20:05 ]

[voodoo202]

ja maar wil je die tabellen ook nog gekoppeld hebben. Ik neem aan dat je ID gebruikt als primary key, en in

artiest: Id met artiest_id.
album: id met album_id
info: id met info_id

en dan nog een extra tabel met de primary key ID en de keys uit de ander tabellen. om ze te koppelen

[Y0ur1]

gorgi_19 schreef op 19 June 2003 @ 20:03:
Een artiest is toch uniek?

Evenals dat een album uniek is.. Je hoeft imho dus niet EN een uniek ID te genereren en er zelf eentje toe te wijzen...

ah das natuurlijk waar ja, 2 dezelfde artiesten zijn er niet en albums ook niet.

[Y0ur1]

voodoo202 schreef op 19 June 2003 @ 20:04:
ja maar wil je die tabellen ook nog gekoppeld hebben. Ik neem aan dat je ID gebruikt als primary key, en in

artiest: Id met artiest_id.
album: id met album_id
info: id met info_id

en dan nog een extra tabel met de primary key ID en de keys uit de ander tabellen. om ze te koppelen

Ik haal toch al in mijn tabel 'album' artiest_id, dan is hij toch gekoppeld

[voodoo202]

Ik weet niet of je normaliseren van een database ooit hebt gehad op school. Maar je schrijft eerst alle velden op, die zet je in de nulde normaal vorm, dan in de 1e dan 2e 3e en evt 4e.

[Y0ur1]

voodoo202 schreef op 19 juni 2003 @ 20:07:
Ik weet niet of je normaliseren van een database ooit hebt gehad op school. Maar je schrijft eerst alle velden op, die zet je in de nulde normaal vorm, dan in de 1e dan 2e 3e en evt 4e.

nu snap ik er nog minder van

[gorgi_19]

Ik mis trouwens ook de tabel tracks..
Ik ga er tenminste niet van uit dat je tracks als csv-lijst gaat opslaan?

YT-Croc schreef op 19 juni 2003 @ 20:06:
[...]


Ik haal toch al in mijn tabel 'album' artiest_id, dan is hij toch gekoppeld

1 album heeft 1 of meer artiesten (denk aan verzamelalbums.. )

voodoo202 schreef op 19 juni 2003 @ 20:07:
Ik weet niet of je normaliseren van een database ooit hebt gehad op school. Maar je schrijft eerst alle velden op, die zet je in de nulde normaal vorm, dan in de 1e dan 2e 3e en evt 4e.

4e normaalvorm wordt nauwelijks gebruikt. Maar normaliseren is alleen een hulpmiddel om tot een goed databasemodel te komen. Je kan imho ook stappen overslaan, als je de exercitie vaak genoeg hebt gedaan...

[ Voor 41% gewijzigd door gorgi_19 op 19-06-2003 20:11 ]

[Y0ur1]

gorgi_19 schreef op 19 juni 2003 @ 20:09:
Ik mis trouwens ook de tabel tracks..
Ik ga er tenminste niet van uit dat je tracks als csv-lijst gaat opslaan?


[...]

1 album heeft 1 of meer artiesten (denk aan verzamelalbums.. )

daar ga ik niet van uit, ik heb sowieso geen verzamelalbums.

[Arnaud]

Waarom zouden er niet twee dezelfde artiesten kunnen zijn? Er zijn toch ook meerdere Jan Jansens? Datzelfde geld voor een album.

Daarnaast kunnen er op een album nummers van meerdere artiesten staan (verzamelcd's) en kan een artiest meerdere albums hebben uitgebracht. Dit lijkt me eerdere een n-n dan een 1-n oplossing.

Beschouw je dit meer als een oefening dan zou ik je aanraden om lekker door te gaan, wil je echt iets moois dan zou ik naar een kant-en-klare database hiervoor gaan zoeken.

[Verwijderd]

code:

tabel artiest:
id
artiest_naam

tabel artiest_album
artiest_id
album_id

tabel album:
id
album_naam

tabel info:
id
album_id
bitrate
tracks

Nu kan je meerdere artiesten aan 1 album koppelen dmv een koppel tabel.

[gorgi_19]

Arnaud schreef op 19 June 2003 @ 20:12:
Waarom zouden er niet twee dezelfde artiesten kunnen zijn? Er zijn toch ook meerdere Jan Jansens? Datzelfde geld voor een album.

Die hebben allebei een uniek ID

Beschouw je dit meer als een oefening dan zou ik je aanraden om lekker door te gaan, wil je echt iets moois dan zou ik naar een kant-en-klare database hiervoor gaan zoeken.

Zo iets maken iets niet zo heel moeilijk..

----
Is trouwens de kolom info_id niet volstrekt nutteloos, aangezien er een 1:1 relatie bestaat tussen album en info?

[ Voor 11% gewijzigd door gorgi_19 op 19-06-2003 20:14 ]

[Y0ur1]

ok nieuw design

code:

tabel artiest:
artiest_id (Prim. key) (uniek artiest id)
artiest_naam (naam v/d artiest)

code:

tabel album:
album_id (Prim. key) (uniek album id)
album_naam (naam v/h album)
artiest_id (het id van de artiest van het album uit tabel 'artiest')
info_id (uit tabel 'info')

code:

tabel info:
info_id (Prim. key) (uniek id voor info)
album_id (id van het album uit tabel 'album')
bitrate (bitrate v/h de cd)
tracks (hoeveel tracks er op de cd staan)

code:

tabel tracks:
tracks_id (Prim key)
tracks (namen v/d tracks)
album_id (uit tabel 'album')

[ Voor 19% gewijzigd door Y0ur1 op 19-06-2003 20:49 ]

[Y0ur1]

Arnaud schreef op 19 June 2003 @ 20:12:
Waarom zouden er niet twee dezelfde artiesten kunnen zijn? Er zijn toch ook meerdere Jan Jansens? Datzelfde geld voor een album.

Daarnaast kunnen er op een album nummers van meerdere artiesten staan (verzamelcd's) en kan een artiest meerdere albums hebben uitgebracht. Dit lijkt me eerdere een n-n dan een 1-n oplossing.

Beschouw je dit meer als een oefening dan zou ik je aanraden om lekker door te gaan, wil je echt iets moois dan zou ik naar een kant-en-klare database hiervoor gaan zoeken.

Ik ga het mooi zelf maken, het is ook meer om te oefenen en om er wat beter in te worden. Heeft iemand een idee hoe ik het veld 'tracks' kan gaan vullen in de tabel 'tracks'?
Watn dat moet iets worden als:
1. track 1
2. track 2
3. track 2

etc....

[ Voor 15% gewijzigd door Y0ur1 op 19-06-2003 20:21 ]

[Arnaud]

--------------------------------------------------------------------------------
Arnaud schreef op 19 June 2003 @ 20:12:
Waarom zouden er niet twee dezelfde artiesten kunnen zijn? Er zijn toch ook meerdere Jan Jansens? Datzelfde geld voor een album.


--------------------------------------------------------------------------------

Die hebben allebei een uniek ID

Maar aangezien je alleen je post welke kolommen in welke tabellen staan, maar niets zegt over de relaties daartussen weet niemand hoe je data koppelt. Bovendien betekent dit dat je nu van album "hoempahoempa" moet gaan opgeven dat het van artiest "17412" is in plaats van "slimme jantje".

Een echt goed database-ontwerp maken voor zoiets "simpels" als dit lijkt makkelijker dan het is. Als jij er al vanuit gaat dat er geen verzamelcd's komen loop je snel genoeg tegen de fouten in je database-ontwerp aan.

Om aan te geven waarom dit moeilijker is dan je denkt: Stel dat een artiest zijn plaat uitbrengt op CD en op DVD. De DVD bevat 1 extra track. Hoe los je dit dan op in je database-ontwerp?

Mijn tip is om een database-ontwerp perfect op te zetten volgens alle ideëen die er al zijn bij het eerste ontwerp. Dingen die je vermoed dat er later bij "zouden kunnen komen (maar waarschijnlijk niet)" moet je ook direct meenemen in je database-ontwerp. Je zult zien dat er in de loop van de tijd vanzelf situaties onstaan waar je nooit aan had gedacht en die je alleen via een omweg in je database-ontwerp kunt krijgen. Begin dus perfect, anders wordt het later zo'n grote puinzooi dat je opnieuw wilt gaan beginnen!

[Y0ur1]

Arnaud schreef op 19 June 2003 @ 20:31:
[...]

Maar aangezien je alleen je post welke kolommen in welke tabellen staan, maar niets zegt over de relaties daartussen weet niemand hoe je data koppelt. Bovendien betekent dit dat je nu van album "hoempahoempa" moet gaan opgeven dat het van artiest "17412" is in plaats van "slimme jantje".

Een echt goed database-ontwerp maken voor zoiets "simpels" als dit lijkt makkelijker dan het is. Als jij er al vanuit gaat dat er geen verzamelcd's komen loop je snel genoeg tegen de fouten in je database-ontwerp aan.

Om aan te geven waarom dit moeilijker is dan je denkt: Stel dat een artiest zijn plaat uitbrengt op CD en op DVD. De DVD bevat 1 extra track. Hoe los je dit dan op in je database-ontwerp?

Mijn tip is om een database-ontwerp perfect op te zetten volgens alle ideëen die er al zijn bij het eerste ontwerp. Dingen die je vermoed dat er later bij "zouden kunnen komen (maar waarschijnlijk niet)" moet je ook direct meenemen in je database-ontwerp. Je zult zien dat er in de loop van de tijd vanzelf situaties onstaan waar je nooit aan had gedacht en die je alleen via een omweg in je database-ontwerp kunt krijgen. Begin dus perfect, anders wordt het later zo'n grote puinzooi dat je opnieuw wilt gaan beginnen!

Yep ik snap helemaal wat je bedoel hoor, maar ik heb toch echt geen verzamelalbums

[gorgi_19]

Arnaud schreef op 19 June 2003 @ 20:31:
Maar aangezien je alleen je post welke kolommen in welke tabellen staan, maar niets zegt over de relaties daartussen weet niemand hoe je data koppelt. Bovendien betekent dit dat je nu van album "hoempahoempa" moet gaan opgeven dat het van artiest "17412" is in plaats van "slimme jantje".

Die relaties zijn in dit geval wel te bedenken, gezien de duidelijke kolomnamen.. Of hij moet erg slecht gaan goochelen.

Om aan te geven waarom dit moeilijker is dan je denkt: Stel dat een artiest zijn plaat uitbrengt op CD en op DVD. De DVD bevat 1 extra track. Hoe los je dit dan op in je database-ontwerp?

2 aparte albums Een heeft de naam: "Melp cd" en de ander "Melp DVD". Allebei hebben ze een eigen record. Evt. kan je nog een kolom media toevoegen aan je kolom albums, en een aparte tabel media.

[Y0ur1]

gorgi_19 schreef op 19 juni 2003 @ 20:35:
[...]

Die relaties zijn in dit geval wel te bedenken, gezien de duidelijke kolomnamen.. Of hij moet erg slecht gaan goochelen.


[...]

2 aparte albums Een heeft de naam: "Melp cd" en de ander "Melp DVD". Allebei hebben ze een eigen record. Evt. kan je nog een kolom media toevoegen aan je kolom albums, en een aparte tabel media.

Ik heb alleen maar cd's hoor Arnaud probeert me meteen de kneepjes van het vak te leren, maar ik ben er net mee begonnen en ben voorlopig alleen maar ff aan eht klooien met dit databaseje

[gorgi_19]

YT-Croc schreef op 19 June 2003 @ 20:39:
Ik heb alleen maar cd's hoor Arnaud probeert me meteen de kneepjes van het vak te leren, maar ik ben er net mee begonnen en ben voorlopig alleen maar ff aan eht klooien met dit databaseje

* gorgi_19 is het alleen niet eens met alles wat hij zegt, vandaar dat ik er graag tegenin ga...

Alleen blijft de vraag voor jou staan: waarom een kolom info_id?

[Y0ur1]

gorgi_19 schreef op 19 June 2003 @ 20:41:
[...]

* gorgi_19 is het alleen niet eens met alles wat hij zegt, vandaar dat ik er graag tegenin ga...

Alleen blijft de vraag voor jou staan: waarom een kolom info_id?

die moet nog tabel 'album' in, was ik vergeten

[Y0ur1]

Weet iemand een programma waarmee ik dit wat meer kan visualiseren? (dus de relatie's leggen tussen tabellen met lijntjes enz) Kan dat met microsoft visio??

[ Voor 27% gewijzigd door Y0ur1 op 19-06-2003 20:54 ]

[gorgi_19]

YT-Croc schreef op 19 June 2003 @ 20:51:
Weet iemand een programma waarmee ik dit wat meer kan visualiseren? (dus de relatie's leggen tussen tabellen met lijntjes enz) Kan dat met microsoft visio??

MS Access kan dat ook.. Visio ook.

[Y0ur1]

gorgi_19 schreef op 19 June 2003 @ 20:55:
[...]

MS Access kan dat ook.. Visio ook.

access
Heb ik ook een keer een database in mogen maken, wat een verschrikking zeg.

[spaceboy]

YT-Croc schreef op 19 June 2003 @ 20:51:
Weet iemand een programma waarmee ik dit wat meer kan visualiseren? (dus de relatie's leggen tussen tabellen met lijntjes enz) Kan dat met microsoft visio??

Gewoon MS Access pakken. Kind kan de was doen.

[gorgi_19]

YT-Croc schreef op 19 June 2003 @ 20:56:
[...]


access
Heb ik ook een keer een database in mogen maken, wat een verschrikking zeg.

Erhm.. Want? Wat is er mis mee? Tuurlijk moet je er geen miljoen records in stoppen...

[spaceboy]

gorgi_19 schreef op 19 June 2003 @ 21:01:
[...]

Erhm.. Want? Wat is er mis mee? Tuurlijk moet je er geen miljoen records in stoppen...

Dan is er een betere uitdaging. Zorg dat je ergens een IMS-database in elkaar kan maken. Heerlijk, een hierarchische database-structuur opzetten. Lekkere front-end erbij proggen in Cobol of PL1 and you're all set.

Echt, voor een beginner (want dan ben je) is Access meer dan prima.

[whoami]

spaceboy schreef op 19 June 2003 @ 22:10:
[...]

Dan is er een betere uitdaging. Zorg dat je ergens een IMS-database in elkaar kan maken. Heerlijk, een hierarchische database-structuur opzetten. Lekkere front-end erbij proggen in Cobol of PL1 and you're all set.

Ja, leuk hierarchische databases. Echter, dat zijn dino's die in het museum thuishoren.
Ik vraag me af waar ze dat momenteel nog gebruiken, hierarchische databases.

[dominic]

spaceboy schreef op 19 juni 2003 @ 20:58:
[...]

Gewoon MS Access pakken. Kind kan de was doen.

Idd, of SQL, iedere stukkie dbase software heeft volgens mij wel ondersteuning voor diagrams..

Even terug op een eerdere opmerking van 'dubbele id's', ik hou er zelf ook altijd van IEDER record in welke tabel dan ook van een primary key en een identity te voorzien.. zo kun je de records in welke situatie dan ook benaderen.

[whoami]

dominic schreef op 19 June 2003 @ 22:18:
[...]


Idd, of SQL, iedere stukkie dbase software heeft volgens mij wel ondersteuning voor diagrams..

Je bedoelt waarschijnlijk SQL Server? SQL is namelijk een taal, en geen DBMS.

Even terug op een eerdere opmerking van 'dubbele id's', ik hou er zelf ook altijd van IEDER record in welke tabel dan ook van een primary key en een identity te voorzien.. zo kun je de records in welke situatie dan ook benaderen.

Bedoel je dan dat je 2 id's hebt per record?
Waarom niet 1 id die een primary key is en ook identity column is? Een primary key moet zowiezo altijd uniek zijn.

[DaRoot]

Heb dit ff beetje gevolgd, ik ben zelf ook een behoorlijke leek op databeest gebied. Maar misschien kun je de topicstarter helpen met een site over basic database design en normaliseren? Daar ben ik eigenlijk ook benieuwd naar.

[gorgi_19]

DaRoot schreef op 19 juni 2003 @ 22:20:
Heb dit ff beetje gevolgd, ik ben zelf ook een behoorlijke leek op databeest gebied. Maar misschien kun je de topicstarter helpen met een site over basic database design en normaliseren? Daar ben ik eigenlijk ook benieuwd naar.

http://home.student.utwen...aper_DB_normalisation.pdf

[whoami]

DaRoot schreef op 19 June 2003 @ 22:20:
Heb dit ff beetje gevolgd, ik ben zelf ook een behoorlijke leek op databeest gebied. Maar misschien kun je de topicstarter helpen met een site over basic database design en normaliseren? Daar ben ik eigenlijk ook benieuwd naar.

Kijk eens in de P&W FAQ.
Klik op inhoudelijke FAQ en dan op het item SQL ofzo. Je vind daar ook wel iets over normalisatie enzo.

[DaRoot]

gorgi_19 schreef op 19 juni 2003 @ 22:22:
[...]

http://home.student.utwen...aper_DB_normalisation.pdf

Kijk eens aan, mij wordt ineens ook weer wat meer duidelijk! Is een duidelijke beschrijving denk ik zo. Many thanks.

whoami schreef op 19 juni 2003 @ 22:22:
[...]


Kijk eens in de P&W FAQ.
Klik op inhoudelijke FAQ en dan op het item SQL ofzo. Je vind daar ook wel iets over normalisatie enzo.

Stom stom stom, had ik zelf ook kunnen kijken inderdaad. Ik kom eigenlijk nooit in dit subforum, vandaar.

[ Voor 37% gewijzigd door DaRoot op 19-06-2003 22:32 ]

[Arnaud]

Om aan te geven waarom dit moeilijker is dan je denkt: Stel dat een artiest zijn plaat uitbrengt op CD en op DVD. De DVD bevat 1 extra track. Hoe los je dit dan op in je database-ontwerp?


--------------------------------------------------------------------------------

2 aparte albums Een heeft de naam: "Melp cd" en de ander "Melp DVD". Allebei hebben ze een eigen record. Evt. kan je nog een kolom media toevoegen aan je kolom albums, en een aparte tabel media.

--------------------------------------------------------------------------------

Uiteraard 2 aparte albums, want ook dingen als releasedatum, uitgever, etc kunnen verschillend zijn. Het probleem dat ik probeer aan te geven is dat je in eerste instantie denkt dat er een 1-n relatie is tussen track en album, terwijl dit later een n-n relatie blijkt te zijn. Als je dit goed wilt normaliseren moet je dus een koppeltabel maken.

"Melp CD" en "Melp DVD" is verboden als je gaat normaliseren omdat je dan een samengestelde key krijgt. Hierdoor kun je later niet meer zoeken op alle CD's en ook de kans op foutieve invoer (zoals "Melp C.D.") is veel te groot waardoor vervuiling ontstaat in je database. Je zult dus inderdaad een extra kolom "Media-type" moeten opnemen die een 1-n relatie heeft met een "opzoek-tabel". Het nadeel is nu dat als een CD en DVD 100% overeenkomen qua tracks (wat vrijwel altijd zo zal zijn), je nu veel meer invoerwerk hebt door al dat genormaliseer.

De moraal van dit verhaal: Normaliseer in eerste instantie perfect, maar later kom je erachter dat het nog altijd niet goed genoeg is!

[gorgi_19]

Arnaud schreef op 19 June 2003 @ 23:06:
"Melp CD" en "Melp DVD" is verboden als je gaat normaliseren omdat je dan een samengestelde key krijgt. Hierdoor kun je later niet meer zoeken op alle CD's en ook de kans op foutieve invoer (zoals "Melp C.D.") is veel te groot waardoor vervuiling ontstaat in je database. Je zult dus inderdaad een extra kolom "Media-type" moeten opnemen die een 1-n relatie heeft met een "opzoek-tabel". Het nadeel is nu dat als een CD en DVD 100% overeenkomen qua tracks (wat vrijwel altijd zo zal zijn), je nu veel meer invoerwerk hebt door al dat genormaliseer.

't is maar hoe je het beschouwd.. Als je een album beschouwd als muziekdrager, irrelevant als mediatype, dan kan je het wel toevoegen.. Maar ik geloof dat ik hierover al iets eerder wat had gezegd...

gorgi_19 schreef op 19 juni 2003 @ 20:35:
2 aparte albums Een heeft de naam: "Melp cd" en de ander "Melp DVD". Allebei hebben ze een eigen record. Evt. kan je nog een kolom media toevoegen aan je kolom albums, en een aparte tabel media.

[Y0ur1]

ok bedankt voor de reactie's, ben weer wat wijzer

[ Voor 9% gewijzigd door Y0ur1 op 20-06-2003 01:43 ]

[spaceboy]

whoami schreef op 19 June 2003 @ 22:12:
[...]


Ja, leuk hierarchische databases. Echter, dat zijn dino's die in het museum thuishoren.
Ik vraag me af waar ze dat momenteel nog gebruiken, hierarchische databases.

Ga maar 's bij de Amev werken... Reken maar dat er een paar miljoen verzekerden in Nederland rondlopen die vrolijk met hun gegevens in een hierarchische database staan.

[trekker22]

gorgi_19 schreef op 19 June 2003 @ 22:22:
[...]

http://home.student.utwen...aper_DB_normalisation.pdf

Ik heb dit documentje ook even gelezen, maar ik snap niet echt het nut van de laatste stap die ze maken: het verschuiven van postcode en woonplaats naar een aparte tabel.

- In welke gevallen levert dit een "anomalie" op?

- Kan iemand me een concreet voorbeeld geven wanneer dit nut heeft?

Als ik een DB maak met persoonsgegevens en er zit postcode/woonplaats bij, dan zet ik dit gewoon in de persoon tabel en ga geen extra tabel aanmaken.

[ Voor 4% gewijzigd door trekker22 op 20-06-2003 11:04 ]

[whoami]

trekker22 schreef op 20 juni 2003 @ 11:04:
[...]

Als ik een DB maak met persoonsgegevens en er zit postcode/woonplaats bij, dan zet ik dit gewoon in de persoon tabel en ga geen extra tabel aanmaken.

Dan ga jij tientallen keren dezelfde informatie opslaan?
Als er dan in je tabel Persoon, 2 of meerdere personen zijn die in dezelfde gemeente wonen, dan ga jij iedere keer diezelfde gegevens gaan opslaan?
Stel dat de gemeente dan van naam veranderd, of de postcode veranderd, hoeveel keer ga jij dan die aanpassing moeten doen?

[heuveltje]

trekker22 schreef op 20 June 2003 @ 11:04:
[...]


Ik heb dit documentje ook even gelezen, maar ik snap niet echt het nut van de laatste stap die ze maken: het verschuiven van postcode en woonplaats naar een aparte tabel.

- In welke gevallen levert dit een "anomalie" op?

- Kan iemand me een concreet voorbeeld geven wanneer dit nut heeft?

Als ik een DB maak met persoonsgegevens en er zit postcode/woonplaats bij, dan zet ik dit gewoon in de persoon tabel en ga geen extra tabel aanmaken.

1 postcode hoort bij 1 plek.
nu zou er dit in een tabel kunnen staan
5616jw veldhoven
5616jw veldhoven
5616jw amsterdam.

das dus niet goed.
als je het in 1 tabel zet kun je eenvoudig postcode als unique id aanhouden

en je zou nu gewoon van de ptt een db kunnen jatten waar alle postcodes in staan, probleem meteen opgelost

[trekker22]

jullie hebben helemaal gelijk... nooit bij stil gestaan

Bedankt voor de info!

[Y0ur1]

nou die lijntjes met visio gaan nog niet helemaal lekker, maar dit is zon beetje de bedoeling:

[whoami]

Ik vind de naamgeving van je tabellen wat onduidelijk.

En ook die tabel album en info snap ik niet echt goed.
Wat is het veld 'tracks' trouwens in de info tabel?

[Y0ur1]

whoami schreef op 20 juni 2003 @ 12:26:
Ik vind de naamgeving van je tabellen wat onduidelijk.

En ook die tabel album en info snap ik niet echt goed.
Wat is het veld 'tracks' trouwens in de info tabel?

het veld tracks in de info tabel is alleen hoeveel tracks er op het album staan. In de tabel info staat informatie over het albums, en in de tabel album komen de namen van de albums te staan + artiest_id

[gorgi_19]

En dan de volgende vraag.. Waarom zijn album en info 2 aparte tabellen?

[whoami]

YT-Croc schreef op 20 June 2003 @ 12:31:
[...]


het veld tracks in de info tabel is alleen hoeveel tracks er op het album staan.

Ik dacht het al. Dat is dus een calculated field, en is dus totaal niet nodig.
Als je die links over normaliseren nog eens bekijkt, zal je zien dat in de 1ste of 2de Normaalvorm alle calculated fields eruit gaan.
Je kan namelijk dmv een query makkelijk het aantal tracks van een album te weten komen. Dat is de beste en flexibilste manier.
Stel dat je een track toevoegt bij een album of verwijderd van een album, dan moet je iedere keer dat veld gaan updaten.

In de tabel info staan informatie over het albums, en in de tabel album komen de namen van de albums te staan + artiest_id

Waarom kan die informatie niet in de album tabel opgenomen worden?

[gorgi_19]

whoami schreef op 20 June 2003 @ 12:33:
[...]


Ik dacht het al. Dat is dus een calculated field, en is dus totaal niet nodig.

Dat is het niet..
Er is namelijk geen tabel tracks.

[whoami]

gorgi_19 schreef op 20 juni 2003 @ 12:37:
[...]

Dat is het niet..
Er is namelijk geen tabel tracks.

Kijk nog eens goed naar het plaatje jij.

[gorgi_19]

whoami schreef op 20 June 2003 @ 12:39:
[...]


Kijk nog eens goed naar het plaatje jij.

Da's gemeen... Hij heeft het plaatje veranderd ten opzichte van het originele ontwerp...

[ Voor 12% gewijzigd door gorgi_19 op 20-06-2003 12:42 ]

[heuveltje]

ehm ik hem eerlijk gezegd nogal vreemd ..........

je houd per album een bitrate bij. lijkt me dat dat per song moet
je houd een track id bij. maar waarom ? lijkt me dat je wat nuttige info mist in die tabel (songname enzo )
je houd 1 zanger bij per album. solo nummers van bandleden, extra zangers die meedoen en weet ik wat kun je dus niet bijhouden

als je naar info_id verwijst vanuit een album id
waarom hou je in info tabel dan weer een album id bij ?

waarom zijn info en album uberhaupt gescheiden ?

[ Voor 22% gewijzigd door heuveltje op 20-06-2003 12:49 ]

[heuveltje]

persoonlijk zou ik er zoiets van gebakken hebben.

(bovenste hokje is tabelnaam)

[ Voor 13% gewijzigd door heuveltje op 20-06-2003 13:05 ]