Relaties tussen tables en "de regels van de kunst"

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Java developer met testervaring

Java developer met testervaring Functieomschrijving "De drempel tussen de burger en de Belastingdienst zo laag mogelijk houden: dat is de belangrijke taak van ons team. Dit doen we door het burgerportaal Mijn Belastingdienst continu te verbeteren." René, Java-specialist bij de Belastingdienst. De keten Interactie is een samenwerkingsverband van alle dienstonderdelen binnen de Belastingdienst. Samen zorgen we dat het contact met burgers en bedrijven goed kan plaatsvinden. Onze belangrijkste opgave? Zoveel mogelijk digitaliseren. Dat doen we binnen het onderdeel Informatievoorzieningen (IV), de ICT-organisatie van de Belastingdienst. Denk bij de producten die IV-Interactie ontwikkelt en onderhoudt aan portalen, formulieren en authenticatie- en

Bekijk vacature »

Sure Is

Sure Is

29/01/2011 17:34:28
Quote Anchor link
Hi all!

Ik heb 3 tables:
- Winkel
- Rayon
- Kopers

Nu twijfel ik over twee systemen om relaties te leggen tussen deze tables.
Het werkt als volgt:
Een Winkel kan Rayons aanmaken, en daarop bevinden zich producten.
Ik wil bijhouden dat Winkels kunnen zien hoeveel producten zij verkocht hebben,
ingedeeld per Rayon.


Systeem 1:
Ik hou in table Rayon dit bij:
- id1: een unieke id
- id2: de unieke id van de Winkel
- id3: een id voor het Rayon PER Winkel
- en ook nog naam etc. maar dat is hier niet belangrijk

Een voorbeeld:
Rayon1 van Winkel1 krijgt:
id1: (unieke id, bv.1)
id2: 1
id3: 1

Rayon2 van Winkel1 krijgt:
id1: (unieke id, bv.2)
id2: 1
id3: 2

Rayon3 van Winkel1 krijgt:
id1: (unieke id, bv.3)
id2: 1
id3: 3

Rayon1 van Winkel2 krijgt:
id1: (unieke id, bv.4)
id2: 2
id3: 1

Rayon2 van Winkel2 krijgt:
id1: (unieke id, bv.5)
id2: 2
id3: 2


Ik hou in table Kopers dit bij:
- id1: een unieke id
- id2: de unieke id van de Winkel
- id3: de id voor de Rayon per Winkel.
- en ook nog naam etc. maar dat is hier niet belangrijk

Wanneer iemand een product koopt van Rayon 2 van Winkel 3,
dan wordt er opgeslaan in table Kopers:
id1: (unieke id)
id2: 3
id3: 2


Wanneer ik nu op de pagina voor de eigenaar van een Winkel zijn verkochte producten wil tonen,
en die wil indelen per Rayon,
dan doe ik gewoon: "haal mij alle records van Winkel X en deel op volgens Rayons (dus toon eerst alle verkochte producten voor Rayon1, vervolgens voor Rayon2 enzovoort)".


Systeem 2:
Ik hou in table Rayon dit bij:
- id1: een unieke Rayonid
- id2: de unieke id van de Winkel
- en ook nog naam etc. maar dat is hier niet belangrijk

Ik hou in table Kopers dit bij:
- id1: een unieke id
- id2: de unieke Rayonid
- en ook nog naam etc. maar dat is hier niet belangrijk

Ik link dus als volgt:
Product X behoort tot Rayonid Y, en Rayonid Y behoort tot Winkel Z.
Zo weet ik dat product X behoort tot Winkel Z.
De pagina van de Winkel om zijn verkochte producten te tonen,
en in te delen per Rayon, zal dus iets moeilijker zijn om te schrijven,
omdat ik 2 keer die linkt moet achterhalen, en niet gewoon de info uit mijn table kan halen zoals in Systeem1.


Waarom vraag ik dit?
Ik had eerst alles geschreven volgens Systeem1. Dit werkt.
Plots herinnerde ik mij dat er zoiets is als databasenormalisatie en vermijden van gegevensredundantie in u databases.
Ik vreesde dat mijn Systeem1 dus niet volgens de regels van de kunst is,
omdat ik eigenlijk meer info bijhoud dan nodig (ookal maakt het mij makkelijker...)

Iemand die hier advies rond heeft?
Ik zou hem/haar zeer dankbaar zijn :)!

(info: het gaat mij dus niet om HOE dit moet geschreven worden in php, wel om voor welk systeem ik het beste kies)

Groetjes.
Gewijzigd op 29/01/2011 17:36:57 door Sure Is
 
PHP hulp

PHP hulp

27/10/2021 19:33:19
 
Tikkes C

Tikkes C

29/01/2011 19:28:31
Quote Anchor link
Ik zou noch voor 1, noch voor 2 kiezen...
als je nu een tabel "klanten" maakt met klanten_id en persoonlijke gegevens in,
daarnaast heb je een "winkel" tabel met winkel_id en extra info (naam,...)
dan heb je een tabel "rayon" met basis info over rayon, dit is o.a. id, grootte,...

dan maak je een linked tabel...
deze noem je bijvoorbeeld Klanten_rayon, hierin link je enkel klant_id met rayon_id (beiden zijn fk's en samen is dit dan een pk)

dit doe je t zelfde voor winkel en rayon met een link voor beide id's


ik hoop dat ik wat duidelijk ben :)


Klant:
-id
-naam
-...

Rayon:
-id
-...

Klanten-Rayon:
-klant_id (fk)
-rayon_id (fk)
pk: klant_id en rayon_id samen

Winkel:
-id
-...

Rayon-Winkel:
-winkel_id (fk)
-rayon_id (fk)
pk: winkel_id en rayon_id samen
 
Sure Is

Sure Is

30/01/2011 14:10:48
Quote Anchor link
Bedankt van het antwoord!
Ik denk echter dat ik niet met die extra tables ga werken,
ik zie er het nut niet van in omdat mijn systeem maar beperkte dingen moet kunnen.
Minder tables houden het overzichtelijker.
Ik denk dat ik systeem1 ga gebruiken, zonder de id1.
Volgens mij vermijd ik dan evengoed gegevensredundantie en is mijn table genormaliseerd... of ben ik verkeerd?

Thanks again!
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.