Database Ontwerp

[Verwijderd]

Ik ben bezig een site te maken waarop we veel foto's e.d. zullen zetten..
Omdat ik van plan ben dit alles met php/mysql te gaan doen, heb ik de moeite genomen eens een deugelijk dbontwerp te maken.
(Normaal volstaan wat aan trucs wel..)

Dit is het ontwerp;


En hierbij de uitleg;

Ik wil van elke foto een id bij houden, daarbij een onderschrift voor dit plaatje, alsmede de datum van fotograferen en de fotograaf.

De foto kan worden gemaakt op verschillende lokatie's; bij de voetbal, bij het uitgaan of ergens anders.
Van de voetbal en van het uitgaan wil ik nog wat speciale attributen bijhouden, voor die andere is dit niet echt nodig.

Nou zit ik een beetje met een probleem.

Ik heb de relatie Foto - Plek welke ook een aparte id heeft.
Dan krijg ik bv. dit;
FPID -- FID -- PID
1 1 1
2 2 1
3 3 1
4 4 2

Zoals je ziet heeft PID( de ID van de plek) dan steeds dezelfde waarde.. (1e N.V.)
Nu wil ik dat graag verder normaliseren, maar lukt me dat niet zo goed

Hebben jullie beter ideeen voor m'n ontwerp of weten jullie hoe ik dit probleem het best kan oplossen.

edit:

Hier kun je m'n ontwerp downloaden en aanpassen
http://wwwhome.cs.utwente.nl/~toon0247/ontwerp/dbontwerp.png

[dusty]

En de FPID id heeft als doel?

[Nielsz]

Op dinsdag 18 december 2001 14:12 schreef dusty het volgende:
En de FPID id heeft als doel?

Dat je het record uniek kan identificeren

[dusty]

Op dinsdag 18 december 2001 14:13 schreef Nielsz het volgende:
Dat je het record uniek kan identificeren

oh dat betekent dus dat het volgende ook mag ?

1 1 1
2 1 2

?

[djc]

Lijkt me wel.

[Nielsz]

Op dinsdag 18 december 2001 14:14 schreef dusty het volgende:

[..]

oh dat betekent dus dat het volgende ook mag ?

fid!=fpid
Waarom probeer ik het nog steeds

[Nielsz]

Op dinsdag 18 december 2001 14:15 schreef Manuzhai het volgende:
Lijkt me wel.

Het mag wel, maar het zijn allebei al PK, dus een PK over enkel 2 PK's lijkt mij onnodig

[dusty]

Op dinsdag 18 december 2001 14:16 schreef Nielsz het volgende:
fid!=fpid
Waarom probeer ik het nog steeds

tja...

[Goodielover]

Belangrijke vraag die niemand van jullie stelt:
Betaan plekken ook los van foto's?
Of wordt een plek gecreerd als er een foto wordt geplaatst?

[Dash2in1]

Waarom geef je niet alle foto's een uniek nummer en een attribuut van waar ze genomen zijn.
Kan je in een aparte tabel voetbalFoto of wat dan ook deze nummers opnemen met z'n attributen ?!

[dusty]

Op dinsdag 18 december 2001 14:17 schreef Goodielover het volgende:
Belangrijke vraag die niemand van jullie stelt:
Betaan plekken ook los van foto's?
Of wordt een plek gecreerd als er een foto wordt geplaatst?

Irrelevant.

[dusty]

Op dinsdag 18 december 2001 14:18 schreef Dash2in1 het volgende:
Waarom geef je niet alle foto's een uniek nummer en een attribuut van waar ze genomen zijn.
Kan je in een aparte tabel voetbalFoto of wat dan ook deze nummers opnemen met z'n attributen ?!

*Proest*

[Goodielover]

Zullen we ons eerst een beperken tot z'n functionele wensen, zonder direct in de oplossingen te schieten.
Rustig aan mensen, dan gaat het het snelst.

Nog een keer dusty en je staat op mijn ignore lijst

[Janoz]

Kan een foto ook bij meer plekken horen?

[dusty]

Op dinsdag 18 december 2001 14:20 schreef Janoz het volgende:
Kan een foto ook bij meer plekken horen?

die vraag had ik al gesteld joh!

[Wokker]

Ik zou ook nog een aparte tabel bijhouden om de fotografen in bij te houden. Want meerdere foto's die door een fotograaf gemaakt kuinnen worden

[Goodielover]

Op dinsdag 18 december 2001 14:18 schreef dusty het volgende:

[..]

Irrelevant.

NIET DUS.

Het ziet er naar uit dat een foto gewoon op een plek is genomen en de attributen van plek dus gewoon bij foto kunnen.
Als plekken zelfstandig bestaan rechtvaardigt dat een eigen entiteit anders niet.

[djc]

Op dinsdag 18 december 2001 14:24 schreef Wokker het volgende:
Ik zou ook nog een aparte tabel bijhouden om de fotografen in bij te houden. Want meerdere foto's die door een fotograaf gemaakt kuinnen worden

Breng m nou niet op ideeen...

[Dash2in1]

Op dinsdag 18 december 2001 14:19 schreef dusty het volgende:

[..]

*Proest*

edit:
verkeerd gekeken

[Dash2in1]

[quote]Op dinsdag 18 december 2001 14:25 schreef Dash2in1 het volgende:

[..]

edit:
verkeerd gekeken

[djc]

Op dinsdag 18 december 2001 14:24 schreef Goodielover het volgende:

[..]

NIET DUS.

Het ziet er naar uit dat een foto gewoon op een plek is genomen en de attributen van plek dus gewoon bij foto kunnen.
Als plekken zelfstandig bestaan rechtvaardigt dat een eigen entiteit anders niet.

Volgens mij is dat min of meer hetzelfde idee (of dezelfde intentie) als achterhalen of een foto op meerdere plekken moet komen...

[Verwijderd]

Op dinsdag 18 december 2001 14:24 schreef Goodielover het volgende:

[..]

NIET DUS.

Het ziet er naar uit dat een foto gewoon op een plek is genomen en de attributen van plek dus gewoon bij foto kunnen.
Als plekken zelfstandig bestaan rechtvaardigt dat een eigen entiteit anders niet.

Ik kan op 1 plek meerdere foto's maken. Lijkt me niet meer dan logisch dat je dan van plek een entiteit maakt.

[djc]

Op dinsdag 18 december 2001 14:27 schreef fladder het volgende:

[..]

Ik kan op 1 plek meerdere foto's maken. Lijkt me niet meer dan logisch dat je dan van plek een entiteit maakt.

Jahwel, want als dat zo is maak je plek een attribuut van de foto.

[Verwijderd]

Op dinsdag 18 december 2001 14:25 schreef Manuzhai het volgende:
Volgens mij is dat min of meer hetzelfde idee (of dezelfde intentie) als achterhalen of een foto op meerdere plekken moet komen...

Jij kunt 1 en dezelfde foto zowel bij een voetbalwedstrijd als tijdens het uitgaan maken?

[RickN]

Op dinsdag 18 december 2001 14:18 schreef dusty het volgende:

[..]

Irrelevant.

Da's echt wel relevant, als een plek niet los van een foto bestaat kun je van plek gewoon een attribuut van foto maken (lijkt mij zowiezo het meest voordehandliggend)

Op dinsdag 18 december 2001 14:19 schreef dusty het volgende:

[..]

*Proest*

Je bent wel een beetje sumier in je commentaar vind je ook niet? In plaats van het commentaar van andere mensen op zo'n belachelijke manier (en zonder argumenten) af te schieten kun je beter niks zeggen.

[Verwijderd]

Op dinsdag 18 december 2001 14:27 schreef Manuzhai het volgende:

[..]

Jahwel, want als dat zo is maak je plek een attribuut van de foto.

Lekker handig dan als je 100 foto's maakt bij een voetbalwebstrijd. Voor al doe foto's het de uitslag van de wedstrijd als atribuut van die foto invoeren.

[Nielsz]

_{..toch vervelend dat niemand door heeft dat Dusty altijd gelijk heeft..}

[Janoz]

Op dinsdag 18 december 2001 14:27 schreef fladder het volgende:

[..]

Ik kan op 1 plek meerdere foto's maken. Lijkt me niet meer dan logisch dat je dan van plek een entiteit maakt.

idd, ben ik het helemaal mee eens.. Nu maar ff wachten wie bij wie op het ignore lijstje komt

[djc]

Op dinsdag 18 december 2001 14:28 schreef fladder het volgende:

[..]

Jij kunt 1 en dezelfde foto zowel bij een voetbalwedstrijd als tijdens het uitgaan maken?

Als een foto op meerdere plaatsen in de locatie-pagina's moet komen, dan betekent dat dus dat de foto onafhankelijk is van de locatie. Maakt niet uit waar hij gemaakt is.

[RickN]

Op dinsdag 18 december 2001 14:27 schreef fladder het volgende:

[..]

Ik kan op 1 plek meerdere foto's maken. Lijkt me niet meer dan logisch dat je dan van plek een entiteit maakt.

Idd, maar dat rechtvaardigt niet de beslissing om vervolgens ook maar een relatie Foto-Plaats te maken. Plaats kan toch gewoon een attribuut van foto blijven. Als je al je foto's een uniek nummer geeft is wordt Plaats gewoon een foreign key in je foto tabel... no problem zou ik zeggen.

[Goodielover]

Op dinsdag 18 december 2001 14:27 schreef Manuzhai het volgende:

[..]

Jahwel, want als dat zo is maak je plek een attribuut van de foto.

Kan 1 plek meerdere foto's hebben is de vraag.
Ik denk van niet. Hooguit bij 1 voetbal wedstrijd.
Dan volstaat het opnemen van een FKey bij foto voor een verwijzing naar de plek.

Waar is trouwens onze topic starter in deze discussie.
Het is toch zijn probleem?

[Nielsz]

1 foto kan ook op 2 plekken komen,
stel je neemt een foto van de eiffeltoren af.

Dan kan hij in 'fotos steden' en in 'rivieren'

[Dash2in1]

Op dinsdag 18 december 2001 14:30 schreef RickN het volgende:

[..]

Idd, maar dat rechtvaardigt niet de beslissing om vervolgens ook maar een relatie Foto-Plaats te maken. Plaats kan toch gewoon een attribuut van foto blijven. Als je al je foto's een uniek nummer geeft is wordt Plaats gewoon een foreign key in je foto tabel... no problem zou ik zeggen.

Daar kreeg ik nou een *proest* op van Dusty

[Janoz]

Hij heeft hier de volgende verbinding:

foto *--* plek

IMHO is dit in dit model alleen gerechtvaardigd als ze ook voetballen tijdens het uitgaan... Persoonlijk zou ik een

foto *--1 plek

verbinding kiezen.

[djc]

Op dinsdag 18 december 2001 14:35 schreef Janoz het volgende:
Hij heeft hier de volgende verbinding:

foto *--* plek

IMHO is dit in dit model alleen gerechtvaardigd als ze ook voetballen tijdens het uitgaan... Persoonlijk zou ik een

foto *--1 plek

verbinding kiezen.

Dan kan je beter een plek attribuut aan de foto's toevoegen...

[FoxzMan]

Op dinsdag 18 december 2001 14:24 schreef Wokker het volgende:
Ik zou ook nog een aparte tabel bijhouden om de fotografen in bij te houden. Want meerdere foto's die door een fotograaf gemaakt kuinnen worden

Je kan toch ook een extra kolom aan Foto hangen met kolomnaam Fotograaf.
't lijkt me niet echt allemaal nodig om gegevens van een fotograaf bij te gaan houden....kan wel maar dan krijg je dus een extra tabel met weer een relatie.

[Verwijderd]

Op dinsdag 18 december 2001 14:35 schreef Janoz het volgende:
Hij heeft hier de volgende verbinding:

foto *--* plek

IMHO is dit in dit model alleen gerechtvaardigd als ze ook voetballen tijdens het uitgaan... Persoonlijk zou ik een

foto *--1 plek

verbinding kiezen.

Mee eens.

[dusty]

Op dinsdag 18 december 2001 14:28 schreef RickN het volgende:
Je bent wel een beetje sumier in je commentaar vind je ook niet? In plaats van het commentaar van andere mensen op zo'n belachelijke manier (en zonder argumenten) af te schieten kun je beter niks zeggen.

uit de originele vraag:

Nu wil ik dat graag verder normaliseren

Zijn 'oplossing' was dus NIET verder normaliseren, meer de-normaliseren. Als iemand geen flauw idee heeft waarover hij het heeft ga ik niet precies uitleggen waarom hij fout zit, kan hij zelf ontdekken zodra hij een beetje research doet, doet hij die research niet is hij er niet in geintresseerd.

[Nielsz]

Op dinsdag 18 december 2001 14:36 schreef Manuzhai het volgende:

[..]

Dan kan je beter een plek attribuut aan de foto's toevoegen...

Zegt hij dat niet

[drm]

Op dinsdag 18 december 2001 14:30 schreef RickN het volgende:
Idd, maar dat rechtvaardigt niet de beslissing om vervolgens ook maar een relatie Foto-Plaats te maken.

* drm kan het niet laten

*proest*

Sorry hoor, maar dat slaat helemaal nergens op. Waarom zou je ergens een entiteit van maken en die entiteit niet in relatie brengen met (een) andere entiteit(en)

* drm denkt aan normalizeren

Plaats kan toch gewoon een attribuut van foto blijven. Als je al je foto's een uniek nummer geeft is wordt Plaats gewoon een foreign key in je foto tabel... no problem zou ik zeggen.

En een foreign key is geen relatie Volgens mij ben je een beetje in de war met N:M relaties en evt. relatie-entiteit

[RickN]

Op dinsdag 18 december 2001 14:30 schreef Nielsz het volgende:
_{..toch vervelend dat niemand door heeft dat Dusty altijd gelijk heeft..}

*proest*

Op dinsdag 18 december 2001 14:34 schreef Dash2in1 het volgende:

[..]

Daar kreeg ik nou een *proest* op van Dusty

Ja, en dat boeit me dus niks. Laat em eerst maar eens met argumenten komen.

Hij vind zichzelf wel erg interesant (en sommige anderen helaas ook), maar ik ben nog nooit echt onder de indruk geweest van wat ie allemaal roept op dit forum...

[djc]

Op dinsdag 18 december 2001 14:37 schreef Nielsz het volgende:

[..]

Zegt hij dat niet

Niet noodzakelijk.

[dusty]

Op dinsdag 18 december 2001 14:36 schreef FoxzMan het volgende:
Je kan toch ook een extra kolom aan Foto hangen met kolomnaam Fotograaf.
't lijkt me niet echt allemaal nodig om gegevens van een fotograaf bij te gaan houden....kan wel maar dan krijg je dus een extra tabel met weer een relatie.

Tja, dat je dan de naam maar een keer fout kan typen is een ander punt, type jij de naam van de fotograaf maar lekker op 20 verschillende manieren.

[Verwijderd]

Omdat Janos wel aardig wat krediet bij me heeft neem ik zijn oplossing even wat serieuzer dan andere (Niet dat die niet goed zijn)

Maar je bedoelt dus 1 vaste plek.
Moet ik daarbij als attribuut bijhouden welke plek ? En geen specialisatie toekennen ??

Ik denk dat ik dan van 2 aparte entiteiten; voetbal en uitgaan dezelfde geg. dubbelop bijhoudt.

Bv. ID en Naam hebben ze beide als attribuut, dus zouden die als een generalisatie entiteit gebruikt kunnen worden.

[RickN]

Op dinsdag 18 december 2001 14:37 schreef dusty het volgende:

[..]

uit de originele vraag:
[..]

Zijn 'oplossing' was dus NIET verder normaliseren, meer de-normaliseren. Als iemand geen flauw idee heeft waarover hij het heeft ga ik niet precies uitleggen waarom hij fout zit, kan hij zelf ontdekken zodra hij een beetje research doet, doet hij die research niet is hij er niet in geintresseerd.

Is begrijpelijk, maar dan moet je gewoon helemaal niks zeggen IMHO

[Nielsz]

Op dinsdag 18 december 2001 14:38 schreef Manuzhai het volgende:

[..]

Niet noodzakelijk.

Mag jij het me nu ff uitleggen

[djc]

Op dinsdag 18 december 2001 14:41 schreef Nielsz het volgende:

[..]

Mag jij het me nu ff uitleggen

Een hele joepie table met daarin fid en pid ofzow. Maar dat is heel erg loos, dus op zich heb je wel gelijk.

[RickN]

Op dinsdag 18 december 2001 14:37 schreef drm het volgende:

[..]

* drm kan het niet laten

*proest*

Sorry hoor, maar dat slaat helemaal nergens op. Waarom zou je ergens een entiteit van maken en die entiteit niet in relatie brengen met (een) andere entiteit(en)

* drm denkt aan normalizeren
[..]

En een foreign key is geen relatie Volgens mij ben je een beetje in de war met N:M relaties en evt. relatie-entiteit

Ja, databases boeien me eigenlijk niet zoveel, so forgive me als ik wat van de buzzwords verkeerd gebruik. Wat ik bedoel is dat hij volgens mijn die tabel met (FPID -- FID -- PID) niet nodig heeft.

[djc]

Op dinsdag 18 december 2001 14:43 schreef RickN het volgende:

[..]

Ja, databases boeien me eigenlijk niet zoveel, so forgive me als ik wat van de buzzwords verkeerd gebruik. Wat ik bedoel is dat hij volgens mijn die tabel met (FPID -- FID -- PID) niet nodig heeft.

Daar is iedereen het mee eens... volgens mij.

[Arnout]

Op dinsdag 18 december 2001 14:43 schreef RickN het volgende:

[..]

Ja, databases boeien me eigenlijk niet zoveel, so forgive me als ik wat van de buzzwords verkeerd gebruik. Wat ik bedoel is dat hij volgens mijn die tabel met (FPID -- FID -- PID) niet nodig heeft.

Dat is alleen im frage als je N op N relaties hebt, in deze situatie zoals hierboven geconcludeerd al niet relevant (hoewel het ERD dit wél vermeld).

[drm]

Janoz zei dat een foto n:1 plek relatie beter is

mee eens.

dusty:
Tja, dat je dan de naam maar een keer fout kan typen is een ander punt, type jij de naam van de fotograaf maar lekker op 20 verschillende manieren.

Mwah. Ligt er een beetje aan. Als je verwacht dat je fotografen gaat krijgen die meerdere foto's inleveren dan gaat een entiteit fotograaf body krijgen.

Maar als het er so to speak op neer komt dat je 200 foto's hebt en 198 fotografen en niet van plan bent meer informatie over de fotograaf op te slaan, zou ik het ook niet uitnormaliseren.

_edit:

MetHod:
(...)
(hoewel het ERD dit wél vermeld).

die is ook redelijk outdated na deze discussie, volgens mij

[dusty]

Op dinsdag 18 december 2001 14:35 schreef Janoz het volgende:
Hij heeft hier de volgende verbinding:
IMHO is dit in dit model alleen gerechtvaardigd als ze ook voetballen tijdens het uitgaan... Persoonlijk zou ik een

je bent het woordje KUNNEN vergeten.

[Nielsz]

Op dinsdag 18 december 2001 14:59 schreef drm het volgende:

[..]

mee eens.
[..]

Mwah. Ligt er een beetje aan. Als je verwacht dat je fotografen gaat krijgen die meerdere foto's inleveren dan gaat een entiteit fotograaf body krijgen.

Maar als het er so to speak op neer komt dat je 200 foto's hebt en 198 fotografen en niet van plan bent meer informatie over de fotograaf op te slaan, zou ik het ook niet uitnormaliseren.

_edit:
[..]

die is ook redelijk outdated na deze discussie, volgens mij

Maar als je nou 2 mensen met dezelfde naam hebt? Dan moet je wel meer info verschaffen, en ben je de lul

[dusty]

Op dinsdag 18 december 2001 14:59 schreef drm het volgende:
Mwah. Ligt er een beetje aan. Als je verwacht dat je fotografen gaat krijgen die meerdere foto's inleveren dan gaat een entiteit fotograaf body krijgen.

Je verwacht ook meerdere foto's per voetbal wedstrijd, dus de kans dat er meerdere foto's van dezelfde fotograaf komen is aanzienlijk.

Bovendien heb je meteen je uitbereidings mogelijkheden opengezet ( I.E. CMS-systemen waarbij fotograven zelf foto's kunnen toevoegen e.d. )

[Arnout]

Op dinsdag 18 december 2001 15:04 schreef dusty het volgende:

[..]

Je verwacht ook meerdere foto's per voetbal wedstrijd, dus de kans dat er meerdere foto's van dezelfde fotograaf komen is aanzienlijk.

Bovendien heb je meteen je uitbereidings mogelijkheden opengezet ( I.E. CMS-systemen waarbij fotograven zelf foto's kunnen toevoegen e.d. )

Ok maar de vraag blijft: wel of geen entiteit fotograaf?

(De database zal qua uitbreidbaarheid direct wel hoger scoren, maar is dat het enige voordeel?)

[drm]

Op dinsdag 18 december 2001 15:02 schreef Nielsz het volgende:


Maar als je nou 2 mensen met dezelfde naam hebt? Dan moet je wel meer info verschaffen, en ben je de lul

Niet mee eens.
Want je wilt dan bijvoorbeeld weergeven dat je de "Jan Pietersen van de lutjebroekstraat" bedoelt en niet de "Jan Pietersen van de appelschastraat".

Het is imo helemaal niet relevant waar de fotograaf woont, of wat dan ook, dus als er 2 fotografen met dezelfde naam zijn, dat is dan prima. Balen voor hen dat ze verward worden met elkaar.

dusty:
Je verwacht ook meerdere foto's per voetbal wedstrijd, dus de kans dat er meerdere foto's van dezelfde fotograaf komen is aanzienlijk.

Bovendien heb je meteen je uitbereidings mogelijkheden opengezet ( I.E. CMS-systemen waarbij fotogravfen zelf foto's kunnen toevoegen e.d. )

Het is ook absoluut het overwegen waard, dat ben ik met je eens.

[Nielsz]

Op dinsdag 18 december 2001 15:12 schreef drm het volgende:

[..]

Niet mee eens.
Want je wilt dan bijvoorbeeld weergeven dat je de "Jan Pietersen van de lutjebroekstraat" bedoelt en niet de "Jan Pietersen van de appelschastraat".

Het is imo helemaal niet relevant waar de fotograaf woont, of wat dan ook, dus als er 2 fotografen met dezelfde naam zijn, dat is dan prima. Balen voor hen dat ze verward worden met elkaar.
[..]

zo werkt het natuurlijk niet
"tja, sorry, maareh, drm wilde niet 5 minuten langer werken, dusseh, tja. Jullie zijn gewoon uniek identificeerbaar aan je naam!"

Je baas zal je aan zien komen

[drm]

Op dinsdag 18 december 2001 15:15 schreef Nielsz het volgende:

[..]


zo werkt het natuurlijk niet
"tja, sorry, maareh, drm wilde niet 5 minuten langer werken, dusseh, tja. Jullie zijn gewoon uniek identificeerbaar aan je naam!"

Je baas zal je aan zien komen

Onzin. Dat ligt er maar net aan welke informatievoorziening je wilt bieden. Het gaat tenslotte in de verste verte om de fotograaf. En ik zeg niet dat het niet het overwegen waard is.

Als ik 5 minuten 2 tellen langer moet werken om er een extra tabelletje voor te maken omdat ze wel uniek identificeerbaar moeten zijn, fine.

Maar dat is in dit geval imo niet relevant.

_edit:
daarnaast lees je ook niet goed wat ik zeg:

Op dinsdag 18 december 2001 14:59 schreef ik het volgende:
(...)
Als het er so to speak op neer komt dat je 200 foto's hebt en 198 fotografen en niet van plan bent meer informatie over de fotograaf op te slaan, zou ik het ook niet uitnormaliseren.

Unieke identificeerbaarheid is wel meer informatie over een fotograaf.

[Janoz]

Op dinsdag 18 december 2001 15:01 schreef dusty het volgende:

[..]

je bent het woordje KUNNEN vergeten.

idd

* Janoz bedenkt zich net iets:

Valt het zuipen na afloop van de wedstrijd onder stappen of onder voetbal?

Maar ik denk dat een n:1 relatie in dit geval wel voldoet.

Op dinsdag 18 december 2001 15:06 schreef MetHod het volgende:

[..]

Ok maar de vraag blijft: wel of geen entiteit fotograaf?

(De database zal qua uitbreidbaarheid direct wel hoger scoren, maar is dat het enige voordeel?)

Mwah.. wat is het nadeel van een extra tabel? Queries worden er niet echt moeilijker op, want het is gewoon een simpele relatie.. En het zoeken naar "foto's die door pietje gemaakt zijn" wordt ook een stuk makkelijker... Daarnaast zou je het begrip fotograaf later onderdeel kunnen laten uitmaken van de mensen in het team/ de stapgroep.

* Janoz snapt de angst voor het aantal tabellen van sommige mensen niet.. Waarom probeert iedereen altijd zo weinig mogelijk tabellen te gebruiken?? Als je naar efficientie, onderhoudbaarheid en uitbreidbaarheid streeft moet je juist redundante informatie elimineren, en niet tabellen.

[dusty]

Op dinsdag 18 december 2001 15:18 schreef Janoz het volgende:
Valt het zuipen na afloop van de wedstrijd onder stappen of onder voetbal?

Een persoon ervaart het als een geheel, echter functioneel gezien zou ik het als 2 verschillende onderdelen zien.

* Janoz snapt de angst voor het aantal tabellen van sommige mensen niet.. Waarom probeert iedereen altijd zo weinig mogelijk tabellen te gebruiken?? Als je naar efficientie, onderhoudbaarheid en uitbreidbaarheid streeft moet je juist redundante informatie elimineren, en niet tabellen.

ie. Normaliseren.

[drm]

* drm is het met Janoz en dusty eens

[Arnout]

Op dinsdag 18 december 2001 15:18 schreef Janoz het volgende:
[..]

* Janoz snapt de angst voor het aantal tabellen van sommige mensen niet.. Waarom probeert iedereen altijd zo weinig mogelijk tabellen te gebruiken?? Als je naar efficientie, onderhoudbaarheid en uitbreidbaarheid streeft moet je juist redundante informatie elimineren, en niet tabellen.

Ook meer geplaatst als discussie-booster... ben via bepaalde modules van mijn opleiding vaak in aanraking met database ontwerp en vind dit soort topics wel interessant

* Arnout is eigenlijk best nog wel een n00b eigenlijk op gebied van database ontwerp, ERD's, etc.

[Janoz]

Op dinsdag 18 december 2001 15:21 schreef dusty het volgende:
ie. Normaliseren.

Ik weet dat dat normaliseren is, jij weet dat dat normaliseren is. Vreemd genoeg zijn er nog veel mensen die NIET weten dat dat normaliseren is....

[dusty]

Op dinsdag 18 december 2001 15:23 schreef Janoz het volgende:
Ik weet dat dat normaliseren is, jij weet dat dat normaliseren is. Vreemd genoeg zijn er nog veel mensen die NIET weten dat dat normaliseren is....

Dat weet ik, dat weet jij, ik wou het even laten weten aan de mensen die het nog NIET wisten

[Janoz]

Op dinsdag 18 december 2001 15:23 schreef MetHod het volgende:

[..]

Ook meer geplaatst als discussie-booster... ben via bepaalde modules van mijn opleiding vaak in aanraking met database ontwerp en vind dit soort topics wel interessant

Was ook niet specifiek tegen jou gericht hoor , gewoon een aanvulling op de reactie op je discussie booster.

[Verwijderd]

Er komen maar 2 fotografen hoor (waarvan ik niet alle info op wil slaan..)

Maar nu snap ik nog niet precies wat jullie willen.

Ik heb dus 1 fototabel (attributen zijn bekend, inl. fotograaf)
1 plektabel (ik weet niet precies hoe jullie zien)

En that's is ?

[Nielsz]

Op dinsdag 18 december 2001 15:31 schreef Tizzwat het volgende:
Er komen maar 2 fotografen hoor (waarvan ik niet alle info op wil slaan..)

Maar nu snap ik nog niet precies wat jullie willen.

Ik heb dus 1 fototabel (attributen zijn bekend, inl. fotograaf)
1 plektabel (ik weet niet precies hoe jullie zien)

En that's is ?

foto
====
fid
pid
url
fotograaf(id )

plek
====
pid
plaats
text

fotograaf
====
fgid
voornaam
achternaam
tussenvoegsel


noem maar op. Veel meer is er toch niet meer te vertellen?
[ * Nielsz is ook databasefan ]

[drm]

Op dinsdag 18 december 2001 15:31 schreef Tizzwat het volgende:
Er komen maar 2 fotografen hoor (waarvan ik niet alle info op wil slaan..)

Maar nu snap ik nog niet precies wat jullie willen.

Ik heb dus 1 fototabel (attributen zijn bekend, inl. fotograaf)
1 plektabel (ik weet niet precies hoe jullie zien)

En that's is ?

+1 fotograaf tabel. Als je maar 2 fotografen hebt moet je het definitely uitnormaliseren.

[FoxzMan]

Op dinsdag 18 december 2001 15:31 schreef Tizzwat het volgende:
Er komen maar 2 fotografen hoor (waarvan ik niet alle info op wil slaan..)

Maar nu snap ik nog niet precies wat jullie willen.

Ik heb dus 1 fototabel (attributen zijn bekend, inl. fotograaf)
1 plektabel (ik weet niet precies hoe jullie zien)

En that's is ?

edit:

Wat Nielsz zegt kan dus ook, is je eigen keuze.

Voor die 2 fotografen kun je dus een extra kolomnaam toevoegen aan de tabel foto. Zo kun je zien door wie de foto gemaakt is, ze hebben lijkt mij een andere naam...dus de fotograaf is identificeerbaar.

Wat de plektabel .... daar ben ik ook nog niet uit.

[dusty]

Op dinsdag 18 december 2001 15:37 schreef FoxzMan het volgende:

edit:

Wat Nielsz zegt kan dus ook, is je eigen keuze.

En een van die twee is een betere oplossing dan de andere.

[Nielsz]

Op dinsdag 18 december 2001 15:44 schreef dusty het volgende:

[..]

En een van die twee is een betere oplossing dan de andere.

Goh

Ik was ff vergeten dat er nog onderscheidt tussen die plekken was. Vergeet mijn plektabel maar ff

[dusty]

Op dinsdag 18 december 2001 15:47 schreef Nielsz het volgende:
Ik was ff vergeten dat er nog onderscheidt tussen die plekken was. Vergeet mijn plektabel maar ff

Neuh, het is een leuke tabel om mee te starten, nu nog netjes de andere tabellen erbij

[Nielsz]

Anders
====
id
text

Voetbal
====
id
uitslag
zooi

Uitgaan
====
id
zooi

en:
====
fid
AVU(type)
AVU(id)

[dusty]

Op dinsdag 18 december 2001 15:55 schreef Nielsz het volgende:
[... rotzooi ...]

Jij.. Jij.... IN DE HOEK JIJ!.

[drm]

dusty:
Jij.. Jij.... IN DE HOEK JIJ!.

so very true...

[Nielsz]

Op dinsdag 18 december 2001 15:57 schreef dusty het volgende:

[..]

Jij.. Jij.... IN DE HOEK JIJ!.

zoals ik al zei,

[drm]

Nielsz:
zoals ik al zei,

Dat zou je ook nog kunnen zien als:
" Goed he?"
^</flauw>

[Nielsz]

Op dinsdag 18 december 2001 16:03 schreef drm het volgende:

[..]

Dat zou je ook nog kunnen zien als:
" Goed he?"
^</flauw>

Stiekum weet ik niet beter

[Goodielover]

Alle subtypes van plek platslaan in 1 tabel met een type-veld zou ik zeggen.
Met wel een fotograaf tabel.

[Dash2in1]

Op dinsdag 18 december 2001 15:55 schreef Nielsz het volgende:
Anders
====
id
text

Voetbal
====
id
uitslag
zooi

Uitgaan
====
id
zooi

en:
====
fid
AVU(type)
AVU(id)

Dit zullen jullie vast een domme/newbie vraag vinden, maar wat is hier mis mee dan?

[drm]

Op dinsdag 18 december 2001 16:23 schreef Dash2in1 het volgende:

[..]

Dit zullen jullie vast een domme/newbie vraag vinden, maar wat is hier mis mee dan?

Als je een nieuwe fotosoort toe wilt voegen, moet je een extra tabel aanmaken. Maar een nieuwe soort is geen nieuwe entiteit. Is "niet zo netjes"

[Dash2in1]

Op dinsdag 18 december 2001 16:25 schreef drm het volgende:

[..]

Als je een nieuwe fotosoort toe wilt voegen, moet je een extra tabel aanmaken. Maar een nieuwe soort is geen nieuwe entiteit. Is "niet zo netjes"

Hmm, ok, point taken. Bestaan er trouwens OO-databases?

[oZy]

Op dinsdag 18 december 2001 16:23 schreef Dash2in1 het volgende:

[..]

Dit zullen jullie vast een domme/newbie vraag vinden, maar wat is hier mis mee dan?

laat ik ook es een gokje wagen..

lijkt mij nogal fout dat je "anders" "voetbal" "uitgaan" als tabellen neemt.. maak gewoon een hoofdtabel "event", doe daar een "event_type_id" in ofzo,.. maak een "event_types" tabel met o.a. "anders" "voetbal" "uitgaan" .. een tabel voor bijvoorbeeld "voetbal_uitslagen" met "event_id" en "uitslag", zo kan je de andere event specifieke attributen verder ook uit werken en ga zo door.

naast de events heb je een locations tabel (lijkt me enigzins logisch?) daarom vraag ik me af waarom dusty de eerste tabel van nielz niet goedkeurde

events
======
event id
event type id
event general info

event types
===========
event type id
event type name

voetbal uitslagen
=================
event id
uitslag

locations
=========
location id
location type id (optioneel natuurlijk )
location info

etc.

[drm]

Op dinsdag 18 december 2001 16:28 schreef Dash2in1 het volgende:
Hmm, ok, point taken. Bestaan er trouwens OO-databases?

np

Ik gok van niet, maar het zou me eerlijk gezegd niet verbazen.
_{preciezer: het zou me verbazen als ze dat ook een database zouden noemen}

Aan de andere kant lijkt het met niet zo logisch. Een object bestaat tenslotte uit data en uit code. Maar het is nooit ingewikkeld er zelf een layer overheen te coden.

[Nielsz]

Op dinsdag 18 december 2001 16:23 schreef Dash2in1 het volgende:

[..]

Dit zullen jullie vast een domme/newbie vraag vinden, maar wat is hier mis mee dan?

Probeer maar eens met 1 query de andere.zooi te krijgen als je alleen fotos.id hebt

[RickN]

Op dinsdag 18 december 2001 16:28 schreef Dash2in1 het volgende:

[..]

Hmm, ok, point taken. Bestaan er trouwens OO-databases?

Ja, die bestaan, er wordt iig onderzoek naar gedaan. Ze kunnen volgens mij nog niet concureren met relationele DB's

Link naar vakinfo TU/e

[dusty]

Dat elke "plaats type" verschillende aantal attributen heeft betekent nog niet dat elke of zelfs een "plaats type" een eigen tabel behoort te krijgen.

Het blijven allemaal bepaalde attribuut-type bij een bepaalde plaats met bepaalde waarden.

Er mogen wel wat meer mensen wat abstracter gaan denken hier

[Verwijderd]

Op dinsdag 18 december 2001 16:35 schreef RickN het volgende:

Ja, die bestaan, er wordt iig onderzoek naar gedaan. Ze kunnen volgens mij nog niet concureren met relationele DB's

Nu nog niet nee...

Ik heb zelf ook databaseontwerp gehad, en de prof zag in de toekomst veel heil in de OO databases..
Ik weet er zelf verder niks van

[Verwijderd]

Op dinsdag 18 december 2001 15:37 schreef FoxzMan het volgende:
Voor die 2 fotografen kun je dus een extra kolomnaam toevoegen aan de tabel foto. Zo kun je zien door wie de foto gemaakt is, ze hebben lijkt mij een andere naam...dus de fotograaf is identificeerbaar.

Dat is niet handig, stel je hebt 10000 foto's in die db staan, dan heb je ten eerste 10000 maal handmatig de naam van die fotograaf in moeten tikken (en wordt dus ook 10000 maal opgeslagen --> redundantie).

Stel dat er op een bepaald moment een fotograaf bij je komt met de vraag: "Hoeveel foto's van mij heb je in je systeem staan?", "Hoe heet je dan?", "Jan van de Graaf" en jij hebt 15 keer Jan de Graaf, 13 keer Jan van de Graaf, 10 keer Jan de Graaff, nou ja je snapt 'm neem ik aan...

[thomaske]

Op dinsdag 18 december 2001 16:35 schreef RickN het volgende:

[..]

Ja, die bestaan, er wordt iig onderzoek naar gedaan. Ze kunnen volgens mij nog niet concureren met relationele DB's

en voor de geïnteresseerde een linkje naar veel info

[Verwijderd]

Op dinsdag 18 december 2001 15:35 schreef Nielsz het volgende:


foto
====
fid
pid
url
fotograaf(id )

plek
====
pid
plaats
text

fotograaf
====
fgid
voornaam
achternaam
tussenvoegsel


noem maar op. Veel meer is er toch niet meer te vertellen?
[ * Nielsz is ook databasefan ]

Dit is jullie voorstel, waar iedereen zich dus in kan vinden ??

[Verwijderd]

Kan ik niet beter binnen plek ook nog een foreign key(die uniek is) maken naar 2 aparte tabellen Voetbal en Uitgaan ??

Anders moet ik al die attributen die ik voor Voetbal gebruik ook voor Uitgaan gebruiken en vice versa..
Niet efficient.

[Verwijderd]

Dit begint een beetje een "Oh, wat zijn wij goed" topic te worden IMHO.
OK, Er zaten wat ontwerpfoutjes in (FPID), en er was geen rekening gehouden met een fotograaf-ID.
Maar ik heb nog geen echte oplossing gezien voor het voetbal/uitgaan/anders probleem. Die hebben ieder hun eigen fields.
Nou?

[Crazy D]

Op dinsdag 18 december 2001 19:07 schreef Afterlife het volgende:
Maar ik heb nog geen echte oplossing gezien voor het voetbal/uitgaan/anders probleem. Die hebben ieder hun eigen fields.
Nou?

How bout iets als

Lokatie
-------
ID
Omschrijving

LokatieAttributen
-----------------
lokID
attrID
Omschrijving

LokatieAttributenWaardes
------------------------
attrID
Waarde

Idee dus dat je iets krijgt als:

Lokatie
-------
1 Voetbal
2 Uitgaan

LokatieAttributen
-----------------
1 1 Datum
1 2 Score
1 3 Stadion
2 4 Kroegnaam


LokatieAttributenWaardes
------------------------
1 01-01-2001
2 1 - 0
3 De Kuip
4 Cafe Het Roosje

Oh nou vergeet ik nog ergens een ID Nou ja het ging maar even om het idee wat zomaar in me opkwam... You get the point, zeg maar

[Verwijderd]

Het leuke van de Plek-definities van tizzwat (Voetbal, Uitgaan, Anders) is dat ze niet te normaliseren zijn.
Jouw benadering via Attributes en AttributeWaarden is een meer dan bruikbare benadering, maar wanneer je dat normalisatie-juk laat vallen, kan 't waarschijnlijk nog wel ietsje efficienter.

Tip uit het ISAM verleden: velden kunnen soms andere waarden hebben afhankelijk van de context waarin je ze bekijkt...

[Nielsz]

Op dinsdag 18 december 2001 20:36 schreef Afterlife het volgende:
Tip uit het ISAM verleden: velden kunnen soms andere waarden hebben afhankelijk van de context waarin je ze bekijkt...

Logisch, je wilt toch niet lege velden in een table zetten

[Verwijderd]

Op dinsdag 18 december 2001 20:49 schreef Nielsz het volgende:
Logisch, je wilt toch niet lege velden in een table zetten

Probeer dat maar 's te normaliseren...

[dusty]

Op dinsdag 18 december 2001 20:36 schreef Afterlife het volgende:
Het leuke van de Plek-definities van tizzwat (Voetbal, Uitgaan, Anders) is dat ze niet te normaliseren zijn.
[...]

Ze zijn niet te normaliseren door JOU. dat wilt helemaal niet zeggen dat ze niet te normaliseren zijn.

Crazy_D zit heel dicht bij bij een juiste oplossing, echter heeft hij er een tabel teveel bij gezet. ( LokatieAttributenWaardes )

Als je zijn tabellen aanpast kan je op een betere resultaat komen.

Je gaat namelijk een tabel creeren voor de attributen, in deze tabel sla je de lokatie op, en dan geef je ook nog een attribuutID. Voor voetbal krijg je dan 3 attributen (1,2,3) die elk iets betekenen dat kan je vast leggen in een andere tabel. ( attribute-definition-table ).

Waardoor je bij elke voetbal lokatie dus 3 attributen gaat toevoegen, bij uitgaan krijg je er dan bijvoorbeeld maar 2.. en als er geen attributen zijn voeg je er geen toe. Zo krijg je een heel flexibel gedeelte. Daarnaast heeft hij maar 2 plekken.. Echter elke plaats die je aandoet krijgt een nieuwe plekID. Betekent dus dat voetbal verschillende plekID's kan krijgen. Immers ga je verschillende malen naar voetbal en elke keer beschouw je het als een nieuwe plaats (andere ploeg, ander datum, andere score etc..) hetzelfde voor het uitgaan en overig.

Het is zeer zeker netjes te normaliseren. Maar zoals ik al eerder zei er moeten meer mensen wat abstracter gaan denken.

Crazy_D is in iedergeval hard op weg, en daarom heeft ie wel een stempeltje verdient

[Crazy D]

Op woensdag 19 december 2001 08:50 schreef dusty het volgende:
Crazy_D is in iedergeval hard op weg, en daarom heeft ie wel een stempeltje verdient

Woei nog even net voor het eind van het jaar

Eigenlijk leek het me gewoon het meest logische. En omdat ik zoiets al eens een keer heb gehad met een oefen-webshop, waarin we bij artikelen een aantal vrije velden wilden hebben. In de eerste opzet waren dit gewoon 5 veldjes (je moet ergens een grens trekken ) in het artikelbestand, maar da's natuurlijk zo flexibel als een deur van gewapend beton. Dus in versie 2 heb ik toen een soortgelijk iets opgezet, waarbij die vrije velden in een aparte tabel kwamen te staan, gekoppeld aan een artikelgroep (immers, die vrije velden waren gewoon wat extra gegevens, en over het algemeen kun je stellen dat alle artikelen binnen 1 produktgroep wel dezelfde attributen hebben, zoals bij harddisks het aantal Gb en de rpm). En in een aparte tabel uiteindelijk de waardes (artcode + vrijveldid).

Het is zeer zeker netjes te normaliseren. Maar zoals ik al eerder zei er moeten meer mensen wat abstracter gaan denken.

Heb jij zo toevallig een boek cq. een website bij de hand waarvan je zegt, da's een echte musthave? Er zijn natuurlijk wel 3 miljard sites en boeken over databases en sql, maar een hoop van wat ik gezien heb leert je (mij ) meer hoe ik een query moet opbouwen (qua syntax) en een stukje normalizeren, maar ik mis eigenlijk iets waarin wat meer theorie erachter wordt uitgelegt (waarom bv. bij een where statement als eerste de voorwaarde waarmee je het grootste deel van de records filterd).

[Verwijderd]

Ik heb Dusty's raad eens opgevolgd;

Foto;
FID
Datum
PlekID
URL
Onderschrift
FotograafID

Plek;
PlekID
WelkeID
Naam

Voetbal;
WelkeID
Uitslag
Sfeer
Tegenstander
Waar

Uitgaan;
WelkeID
Bier
Vrouwen

Anders;
WelkeID
Tekst

Fotograaf;
fotograafID
Voornaam
Achternaam

Klopt het zo een beetje ??