Toon posts:

Hoe normaliseer ik deze database

Pagina: 1
Acties:

  • Johnsel
  • Registratie: februari 2004
  • Laatst online: 26-04 17:24
Hallo vriendjes :>

Ik heb momenteel een discussie over hoe een bepaalde database genormaliseerd zou moeten worden:

Het gaat om zakken die gekoppelt worden aan een laadbon. Elke bigbag is per definitie uniek. Het enige wat dubbel opgeslagen wordt is het gewicht, puur omdat als je het verder zou afsplitsen je van 1 kolom naar 2 zou gaan.

Elke zak hoort bij 1 laadbon, maar een laadbon heeft meerdere zakken. Een een-op-veel relatie dus.(toch?)
De laadbon is dan weer aan 1 klant gekoppelt, maar een klant heeft ook weer meerdere laadbonnen. Ook weer een-op-veel. (toch?)

Nu is de stelling van mij dat de juiste manier om dit te verwerken in een database is door middel van een extra kolom in de tabel zak en een extra kolom in de tabel laadbon waarin resp. het laadbon nr cq het klantnr komt.

De ander stelt dat hier een aparte koppeltabel voor zou moeten komen, ivm snelheid bij het ophalen van gegevens en het flexibel kunnen aanpassen van de tabellen.

Ik heb hier uiteraard het nodige al over opgezocht. Sommigen beweren dat het wel zou moeten, anderen weer niet.

Moet er dus een koppeltabel bij een een-op-veel relatie komen? Volgens mij maakt het select's allemaal lastiger ivm 3 inner joins ipv 2. Ook wordt het zaknr 2 x opgeslagen. dat je er aan de "1 kant" niet onderuit komt om dit te doen is logisch, maar aan de veel kant kun je het beperken tot een enkele keer.

Wat is hier de juiste manier?

[Voor 12% gewijzigd door Johnsel op 29-01-2010 12:53]


  • MueR
  • Registratie: januari 2004
  • Laatst online: 13:23

MueR

Moderator Devschuur®

is niet lief

Ik zou niet weten waarom je dit moet normaliseren? Het lijkt mij al een prima database structuur. Het gaat vrij weinig extra moeite kosten voor een database om bij een bon alle bags te zoeken (iets met IN() enzo). Dit verder "optimaliseren" is, voor zover ik uit je verhaal kan halen, overkill.

Anyone who gets in between me and my morning coffee should be insecure.
Breng nu uw applicatie naar de kloot. Dat is veel beter! Nu samen met klootopslag. Voor maar €9,95. Doei doei!


  • Johnsel
  • Registratie: februari 2004
  • Laatst online: 26-04 17:24
Dus de bovenste structuur is juist?

  • Thasquealer
  • Registratie: december 2009
  • Laatst online: 12:44
Normaliseren gaat toch juist vanuit een opdracht?
Dit lijkt meer een resultaat, dus wordt het van de verkeerde kant bekeken.

Edit:
Ik zou denk wat minor aanpassingen doen aan de Laadbon-tabel
Ik weet niet wat er met LaadbonNR wordt bedoelt, maar is dit niet overbodig met een laadbonid?
Tevens zou ik op de tabel Laadbon, een FK BigBagID neerzetten. Dan staat er iig per laadbon welke bigbag er aanwezig is.

Dan kan ook de LaadbonID van de tabel Bigbags af.

[Voor 58% gewijzigd door Thasquealer op 29-01-2010 13:08]

Steam


  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator Devschuur®
Aangezien je een een-op-veel relatie hebt zie ik de meerwaarde van de extra koppeltabel niet. Immers heeft je BigBagRelations nu een een-op-een relatie met je BigBags, en dus ik zou hem weg laten, behalve als je verwacht dat een big-bag in de toekomst ook bij meerdere laad-bonnen kan gaan horen, zodat je een veel-op-veel relatie krijgt.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • Johnsel
  • Registratie: februari 2004
  • Laatst online: 26-04 17:24
Dat is precies wat ik dacht.
Rekening houden met toekomstige dingen, prima, maar aangezien het fysiek onmogelijk is om 1 zak op 2 wagens te laden....

edit:
Thasquealer schreef op vrijdag 29 januari 2010 @ 13:02:
Ik zou denk wat minor aanpassingen doen aan de Laadbon-tabel
Ik weet niet wat er met LaadbonNR wordt bedoelt, maar is dit niet overbodig met een laadbonid?
Tevens zou ik op de tabel Laadbon, een FK BigBagID neerzetten. Dan staat er iig per laadbon welke bigbag er aanwezig is.

Dan kan ook de LaadbonID van de tabel Bigbags af.
LaadbonNR is een "custom" nummering en is dus niet gelijk aan het ID

Een laadbon moet een willekeurige hoeveelheid zakken kunnen bevatten, dus het ID (de id's) in de laadbon aangeven mag ook niet.

[Voor 68% gewijzigd door Johnsel op 29-01-2010 13:18]


  • VyperX
  • Registratie: juni 2001
  • Laatst online: 26-11 15:38
Zelfs dan zou het alleen nuttig zijn als je het op korte termijn verwacht. Die BigBagRelations tabel kan je later altijd nog construeren uit de informatie die je op dat moment hebt.

Ook snap ik het argument van extra snelheid bij de tweede optie niet echt... Je moet een extra tabel raadplegen die eigenlijk een 1-op-1 relatie heeft met de BigBags tabel. Of zie ik iets over het hoofd?

My Dwarf Fortress ASCII Reward: ~~@~~####,.".D",.B""


  • leuk_he
  • Registratie: augustus 2000
  • Laatst online: 02-12 12:23

leuk_he

1. Controleer de kabel!

De bovenste,

De onderste impliceert dat 1 bigbag meer laadbonnen kan hebben, iets wat niet het geval is en je dus in de applicatie(/triggers) weer zou moeten begrenzen.
ivm snelheid bij het ophalen van gegevens
Dat heeft niet heel veel met normaliseren te maken. Dat is naderhand optimaliseren.
het flexibel kunnen aanpassen van de tabellen.
Waarom niet 3 tabbellen:

#tabelid
tabelnaam

#kolumid
@tabelid
kolomnaam
kolomtype

#rijid
@kolomid
waarde.


Heel flexibel, helemaal uitgenormaliseerd >:) ;)


spoiler:
Ik hoop dat je snapt dat je dit laatste dus niet letterlijk moet nemen, het enkel om aan te geven dat een te flexibel database ontwerp niet helpt uiteindelijk.

Need more data. We want your specs. Ik ben ook maar dom. anders: forum, ff reggen, ff topic maken
En als je een oplossing hebt gevonden laat het ook ujb ff in dit topic horen.


  • Xiphalon
  • Registratie: juni 2001
  • Nu online
leuk_he schreef op vrijdag 29 januari 2010 @ 13:13:
Heel flexibel, helemaal uitgenormaliseerd >:) ;)
Alleen als je alle semantiek eruit haalt ;)

  • Herr Flicker
  • Registratie: januari 2007
  • Laatst online: 30-11 16:19
Ik heb met Johnsel hier over ook al gediscussieerd.

Ik denk juist dat een koppel tabel wel de juiste manier is.
Er kunnen immers "meerdere" bigbags in 1 laadbon, hoe wil je anders opgeven dat er meerdere zijn ?
Zonder koppel tabel betekend dus voor elke bigbag in 1 laadbon/reservering dat er een nieuwe rij komt.

Dat lijkt mij juist onlogisch.

Ik zou de bigbags in een aparte tabel zetten, daar de bags toevoegen (als er nieuwe komen).
In de koppeltabel geef je aan wat de keuze is geworden van de bags, en dat wordt weer gekoppeld aan de laadbon/reservering.

  • acemoo
  • Registratie: maart 2006
  • Laatst online: 08:17
Herr Flicker schreef op vrijdag 29 januari 2010 @ 13:31:
Ik heb met Johnsel hier over ook al gediscussieerd.

Ik denk juist dat een koppel tabel wel de juiste manier is.
Er kunnen immers "meerdere" bigbags in 1 laadbon, hoe wil je anders opgeven dat er meerdere zijn ?
Zonder koppel tabel betekend dus voor elke bigbag in 1 laadbon/reservering dat er een nieuwe rij komt.

Dat lijkt mij juist onlogisch.

Ik zou de bigbags in een aparte tabel zetten, daar de bags toevoegen (als er nieuwe komen).
In de koppeltabel geef je aan wat de keuze is geworden van de bags, en dat wordt weer gekoppeld aan de laadbon/reservering.
Of je hebt de rijen in een koppel tabel, of je hebt ze in de normale tabel, je zullt ze toch krijgen.

  • Johnsel
  • Registratie: februari 2004
  • Laatst online: 26-04 17:24
De laadbon waar de bigbag bij hoort is een eigenschap (attribute) van die ene unieke bigbag, kan niet meerdere waarden bevatten, en hoort daarom volgens de regels van normalisatie dus bij de tabel bigbags.

Citaat wikipedia:
Een relatie is in 2NF als alle attributen die niet in de sleutel zijn opgenomen, afhankelijk zijn van de gehele sleutel (geen gedeeltelijke afhankelijkheid) . Een relatie met één attribuut als sleutel is automatisch in 2NF.

* voldoet aan de eerste normaalvorm
* alle niet-sleutelattributen zijn functioneel totaal afhankelijk van de primaire sleutel.

edit op edit: toch niet, rij != kolom

[Voor 40% gewijzigd door Johnsel op 29-01-2010 13:43]


  • MueR
  • Registratie: januari 2004
  • Laatst online: 13:23

MueR

Moderator Devschuur®

is niet lief

Herr Flicker schreef op vrijdag 29 januari 2010 @ 13:31:
Ik denk juist dat een koppel tabel wel de juiste manier is.
Wij niet. Per bag heb je maar 1 mogelijkheid, maar 1 laadbon. Het boeit verder totaal niet hoeveel bags er onder een laadbon hangen, die haal je toch snel genoeg op met een simpele query als
SQL:
1
2
3
SELECT bag.BigBagId, bag.Weight, bag.DateTime
FROM BigBag bag
WHERE bag.LaadbonId = 684

Met je koppeltabel ben je nodeloos extra tabellen aan het joinen. Doe dat dus maar niet.

Anyone who gets in between me and my morning coffee should be insecure.
Breng nu uw applicatie naar de kloot. Dat is veel beter! Nu samen met klootopslag. Voor maar €9,95. Doei doei!


  • ppx17
  • Registratie: december 2007
  • Laatst online: 09:42
Herr Flicker schreef op vrijdag 29 januari 2010 @ 13:31:
Ik heb met Johnsel hier over ook al gediscussieerd.

Ik denk juist dat een koppel tabel wel de juiste manier is.
Er kunnen immers "meerdere" bigbags in 1 laadbon, hoe wil je anders opgeven dat er meerdere zijn ?
Zonder koppel tabel betekend dus voor elke bigbag in 1 laadbon/reservering dat er een nieuwe rij komt.

Dat lijkt mij juist onlogisch.

Ik zou de bigbags in een aparte tabel zetten, daar de bags toevoegen (als er nieuwe komen).
In de koppeltabel geef je aan wat de keuze is geworden van de bags, en dat wordt weer gekoppeld aan de laadbon/reservering.
Er stond dat de bigbags uniek zijn (dus per bigbag heb je al een rij) en er staat ook dat elke bigbag op 1 laadbon komt te staan, op welk punt krijg je op deze manier dan dubbele rijen?

Meerdere laadbonnen om aan te koppelen komen er niet en van elke bigbag is al een rij dus daar komt ook niks extra bij. :?

40D | 8 | 50 | 100 | 300


  • NMe
  • Registratie: februari 2004
  • Laatst online: 04-12 13:43

NMe

Quia Ego Sic Dico.

Herr Flicker schreef op vrijdag 29 januari 2010 @ 13:31:
Ik heb met Johnsel hier over ook al gediscussieerd.

Ik denk juist dat een koppel tabel wel de juiste manier is.
Er kunnen immers "meerdere" bigbags in 1 laadbon, hoe wil je anders opgeven dat er meerdere zijn ?
Zonder koppel tabel betekend dus voor elke bigbag in 1 laadbon/reservering dat er een nieuwe rij komt.

Dat lijkt mij juist onlogisch.
1:N-relaties hebben geen koppeltabel nodig, N:M-relaties wel. Als een bigbag meerdere laadbonnen kan hebben én een laadbon meerdere bigbags dan heb je gelijk, en anders zit je gewoon fout. Ik ben dus bang dat je je beginnersboek over normaliseren er weer even bij mag pakken. :)

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • Herr Flicker
  • Registratie: januari 2007
  • Laatst online: 30-11 16:19
MueR schreef op vrijdag 29 januari 2010 @ 13:57:
[...]

Wij niet. Per bag heb je maar 1 mogelijkheid, maar 1 laadbon. Het boeit verder totaal niet hoeveel bags er onder een laadbon hangen, die haal je toch snel genoeg op met een simpele query als
SQL:
1
2
3
SELECT bag.BigBagId, bag.Weight, bag.DateTime
FROM BigBag bag
WHERE bag.LaadbonId = 684

Met je koppeltabel ben je nodeloos extra tabellen aan het joinen. Doe dat dus maar niet.
Ik begrijp hem nu..
Ik geef mijn fout toe. 8)7
Pagina: 1


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Bekijk de onderstaande instellingen en maak je keuze. Meer informatie vind je in ons cookiebeleid.

Functionele en analytische cookies

Deze cookies helpen de website zijn functies uit te voeren en zijn verplicht. Meer details

janee

    Cookies van derden

    Deze cookies kunnen geplaatst worden door derde partijen via ingesloten content en om de gebruikerservaring van de website te verbeteren. Meer details

    janee