[MySQL] Vraag over databasemodel

[japaveh]

Ik ben bezig met het opzetten van een database waarin wij een fabricageproces willen bijhouden. Dit fabricageproces wordt opgesplitst in een aantal stappen (steps) die allemaal in een runtabel verdwijnen. Per stap is het mogelijk om een remark te maken. Deze remarks worden in een aparte remarktabel opgeslagen.

Globaal zien de tabellen er dus op de volgende manier uit.

code:

Tabel Run:
PRIMARY(step) | run_id | user | .. | etc

Tabel remark:
PRIMARY(id) | time_remark | thickness_remark | etc

Nu is mijn vraag de volgende. In welke van de twee tabellen maak je nu de verwijzing naar de andere. Zet je in de Runtabel een kolom met Run.remark_id verwijzend naar remark.id? of zet je in remark een kolom remark.involved_step naar Run.step? Of doe je beide? Of een koppeltabel?, zo ja..wat is daar dan he voordeel van?

Qua code kun je beide zonder problemen maken, maar ik heb nog niet genoeg kennis van DBsystemen om te weten hoe je dit het beste doet. vandaar dat ik de vraag hier maar stel

[Daventry]

Als ik jou verhaaltje goed lees dan heeft elke step 0 of meer remarks, waarbij 0 ook een mogelijkheid is.

in dat geval zou ik bij Remark een verwijzing zetten naar Step (want: elke Remark hoort bij precies 1 Step, terwijl niet elke Step een Remark heeft [en misschien zelfs meer Remarks kan hebben?])

[japaveh]

Daventry schreef op woensdag 09 maart 2005 @ 08:04:
Als ik jou verhaaltje goed lees dan heeft elke step 0 of meer remarks, waarbij 0 ook een mogelijkheid is.

in dat geval zou ik bij Remark een verwijzing zetten naar Step (want: elke Remark hoort bij precies 1 Step, terwijl niet elke Step een Remark heeft [en misschien zelfs meer Remarks kan hebben?])

You are right, 0 is inderdaad ook een mogelijkheid ik zal dit eens in elkaar proggen

[Verwijderd]

Bij een 1:m relatie zet je de foreign key aan de kant van de m. Bij een n:m relatie maak je een koppeltabel welke beide ID's omvat.

Als dus elke remark 1 step kan hebben, maar elke step 0,1 of meerdere remarks, dan is step:remark 1:m, oftewel er komt een FK step_id in de tabel remark.

[japaveh]

Nu is het wel zo, dat een step in principe maar 1 remark heeft.Deze remark is immers opgesplitst. Je praat dan over een 1:1 relatie. Geldt dan dezelfde voorwaarde?

edit: Wacht...hij hoeft natuurlijk niet perse een remark te hebben, dus je hebt dan altijd een 1:m relatie aangezien geen remark ook telt als een remark

[ Voor 33% gewijzigd door japaveh op 09-03-2005 08:24 ]

[Verwijderd]

Per stap is het mogelijk om een remark te maken.

bedoel je een remark of één (1) remark.

1) Als je 'één remark' bedoelt zet je alle attributen van remark tabel in je run tabel, en los je alles op met één tabel.

2) Als je run_id in de tabel remark zet, geeft dit de mogelijkheid om meedere remarks te bewaren voor één stap.

3) Als je remark id in de run tabel zet betekent dit dat een zelfde remark geldig is voor verschillende stappen binnen het fabricageprocess

4) In beide tabellen een ID zetten heeft volgens mij weinig zin. redudantie van gegevens

Volgens mij is 1) of 2) de oplossing die je zoekt, 3) is naar mijn mening vrij onlogische (maar 't zou kunnen)

Je kan van je remark tabel, een tabel maken met voorgedefineerde remarks, dan moet je natuurlijk wel een remark id in je run tabel zetten, maar verhuizen de time_remark en thickness_remark attributen naar de run tabel.

code:

run    (step, user, time, thickness, remark_id)
remark (id, description)

alles hangt dus af van welke functionaliteit je wil.

[Verwijderd]

japaveh schreef op woensdag 09 maart 2005 @ 08:18:
Nu is het wel zo, dat een step in principe maar 1 remark heeft.Deze remark is immers opgesplitst. Je praat dan over een 1:1 relatie. Geldt dan dezelfde voorwaarde?

Als je 0 of 1 remark hebt, hoef je geen 2 tabellen te gebruiken, alles in 1 pot gooien.

[japaveh]

Verwijderd schreef op woensdag 09 maart 2005 @ 08:29:
[...]
bedoel je een remark of één (1) remark.

Nee, het zijn meerdere remarks, welke opgesplitst zijn in een tijdremark, dikteremark etc. Ik wil getalvormige data, graag getalvormig houden en niet in een textvak zetten om hier later statistiek op te kunnen doen. Het zijn dus meerdere remarks en vandaar dat ik dat graag ik een aparte tabel wilde bewaren met een FK. De vraag van mij was..in welke tabel zet ik de FK

2) Als je run_id in de tabel remark zet, geeft dit de mogelijkheid om meedere remarks te bewaren voor één stap.

Dan is dit dus de beste optie. Gegeven daarbij dus het tabelontwerp zoals dat heirboven gegevens is. Er zullen nooit meer soorten remarks bijkomen, dus de tabel zal niet meerdere kolommen nodig hebben

Volgens mij is 1) of 2) de oplossing die je zoekt, 3) is naar mijn mening vrij onlogische (maar 't zou kunnen)

Je kan van je remark tabel, een tabel maken met voorgedefineerde remarks, dan moet je natuurlijk wel een remark id in je run tabel zetten, maar verhuizen de time_remark en thickness_remark attributen naar de run tabel.

code:

run    (step, user, time, thickness, remark_id)
remark (id, description)

alles hangt dus af van welke functionaliteit je wil.

Is dit niet gewoon optie 3? de onlogische dus

[Verwijderd]

japaveh schreef op woensdag 09 maart 2005 @ 08:41:
Is dit niet gewoon optie 3? de onlogische dus

Dit is een variant van optie 1, (1 step met 1 remark) alleen put de eindgebruiker uit een tabel voorgedefineerde remarks ipv dat hij zelf een remark (omschrijving) ingeeft

[curry684]

Verwijderd schreef op woensdag 09 maart 2005 @ 08:32:
[...]

Als je 0 of 1 remark hebt, hoef je geen 2 tabellen te gebruiken, alles in 1 pot gooien.

Depends, als je extreem grote remarks hebt kan het handig zijn om deze middels een optionele 1:1 relatie in een andere tabel op te slaan die je in een andere filegroup opslaat, daarmee de performance verhogend

in de praktijk heb je vrijwel altijd gelijk hoor, maar tis niet 'per definitie' waar

[japaveh]

curry684 schreef op woensdag 09 maart 2005 @ 10:31:
[...]

Depends, als je extreem grote remarks hebt kan het handig zijn om deze middels een optionele 1:1 relatie in een andere tabel op te slaan die je in een andere filegroup opslaat, daarmee de performance verhogend

in de praktijk heb je vrijwel altijd gelijk hoor, maar tis niet 'per definitie' waar

Maar wat nu als je remarks uit meerdere onderdelen bestaan? Het lijkt me dan toch ook handiger om dit 'uit' de runtabel te halen

[Verwijderd]

bestaat uit meerdere onderdelen, wat bedoel je hier juist mee?

Het is niet ongewoon dat een tabel (step) een aantal attributen bevat die functioneel bij elkaar horen (remark, time, thickness), maar daarom hoef je nog geen aparte tabel gaan maken. Maar mijn gevoel is je applicatie niet zo complex dat je het in 2 tabellen moet opsplitsen, wel rekening houden met wat curry684 heeft geschreven (hij heeft 100% gelijk). Alles hangt af welke functionaliteit je wil.

Een ander voorbeeld :
NAW gegevens (naam, voornaam, straat, nummer, postcode, gemeente, tel, email)
Moet je van (straat, nummer, postcode, gemeente) een apart tabel maken?

Nee, als het gaat over een simpel business/naamkaartjes applicatie
Ja, indien het gaat over een complexe CRM applicatie.

Dus zoals ik al zei : Alles hangt af welke functionaliteit je wil.