[Database ontwerp] Welke van de twee?

[Scharnout]

Ik ben nu een beetje mijn database aan het ontwerpen in MySQL. Het moet een database worden met onder andere een relatietabel (als in zakenrelatie). Nu dacht ik dat mooi op te lossen met een tabel met bedrijfsgegevens en een tabel contactpersonen en die te linken met elkaar. Je kan namelijk meerdere contactpersonen hebben binnen een bedrijf. Mijn zakelijk partner kwam toen me teen ander voorstel.

1 tabel met eigenlijk dezelfde inhoud als bij mij de standaardbedrijfsgegevens, aangevuld met een "geslachts"veld (man, vrouw, bedrijf) en een "fkBedrijfsveld" waar dus voor zowel het bedrijf als de contactpersoon moeten worden ingevoerd (contactpersoon met eventueel een ander adres dan het bedrijf) en dan door het fkBedrijfsveld aan elkaar gelinkt worden.

Dus (voorbeeldje):

record 1:
Naam: Scharnout BV
NAWTROEP
fkBedrijfsveld: Scharnout BV (verwijst dus naar zichzelf)

record 2:
Naam: Arno
NAWTROEP
fkBedrijfsveld: Scharnout BV (verwijst dus naar record 1)

Wat ik wil weten is of het technisch mogelijk is om een record naar zichzelf te laten verwijzen (intikken zou ook kunnen, maar dan zit je met intikvouten)?
En als het mogelijk is;
Wat is de beste oplossing?
en wat is de snelste oplossing?

of zijn er nog andere smaken?

Ik ga (na wat artikelen gelezen te hebben over normalisatie) voor mijn eigen methode, maar wil even toetsen of de echte databasebikkels daar net zo over denken.

Ik script met asp/vbscript.

[.GoO]

Waarom niet een aparte tabel met bedrijf? Lijkt me toch beter.. Met functie erbij ofzo.. Op deze manier is het niet goed en krijg je dubbele velden..

[Bootje]

idd een aparte tabel. Anders krijg je een onmogelijk grote tabel. En dat is erg lastig met betrekking tot queries uitvoeren.

En als je later nog andere dingen wil koppelen aan die tabel dan wordt het lastig een goeie foreign key te bepalen. En hoe definier je geslacht bij bedrijf?

Ik zou twee tabellen doen.

[thomaske]

Ik zou persoonlijk de gegevens van personen en bedrijven splitsen.

dus 1 tabel met gegevens van personen en een tabel met de gegevens van bedrijven. Deze kan je aanelkaar koppelen door per persoon aan te geven bij welk bedrijf dat hij/zij hoort (Foreign Key)

[edit] zie ook de antwoorden hierboven!

[.GoO]

Waar heb je trouwens je sleutels staan?

[Janoz]

Ja, mysql kan ODBC aan.. Maar waarom probeert iedereen altijd het aantal tabellen zoveel mogelijk te minimaliseren? Een persoon is toch iets fundamenteel anders dan een bedrijf? Maak er dan ook gewoon 2 tabellen van.

In de structuur die je nu voorsteld is het ook mogenlijk dat een contactpersoon weer een contactpersoon heeft, en dat een bedrijf een contactpersoon is van een persoon, en dat een bedrijf het contactpersoon van een ander bedrijf is etc etc.

Ga gewoon voor de oplossing met meerdere tabellen. en zet in de persoonstabel een link naar de bedrijven waar de personen bij horen.

[Bootje]

Welke entiteiten worden trouwens de sleutel per tabel. Bij bedrijf moet je niet de naam nemen, er kunnen meerdere filialen zijn en dan zit je.

En bij contactpersoon zou ik zeker een id nummer maken voor primaire sleutel. Van namen primaire sleutels maken draait altijd uit op inconsistentie van je db. Er zijn namelijk meerder mensen die Bakker van achteren heten.

edit:

Om een goeie sleutel voor bedrijf te hebben kan je misschien hun kamer van koophandel nummer toevoegen en deze als primaire sleutel gebruiken.
En natuurlijk bij bedrijf een entiteit die gelijk staat aan de primaire sleutel van Contactpersoon, dit is in bedrijf dan de foreign key.

[.GoO]

Op donderdag 06 juni 2002 11:02 schreef Bootje het volgende:
Welke entiteiten worden trouwens de sleutel per tabel. Bij bedrijf moet je niet de naam nemen, er kunnen meerdere filialen zijn en dan zit je.

En bij contactpersoon zou ik zeker een id nummer maken voor primaire sleutel. Van namen primaire sleutels maken draait altijd uit op inconsistentie van je db. Er zijn namelijk meerder mensen die Bakker van achteren heten.

Daarom vroeg ik al wat zn sleutels waren Gewoon die personen een persoonsnr geven en dan linken aan een bedrijfsnr

Naam als sleutel nemen is bij Persoon als Bedrijf heel erg fout..

[Bootje]

Te laat gezien, sorry man! We zitten gelukkig op een lijn!

Jij zat toch ook op de Hogeschool Alkmaar, zal het daar wel aan liggen!

edit:

Zie in je profile dat je ook nog eens dezelfde opleiding doet!

[.GoO]

Op donderdag 06 juni 2002 11:04 schreef Bootje het volgende:
Te laat gezien, sorry man! We zitten gelukkig op een lijn!

Jij zat toch ook op de Hogeschool Alkmaar, zal het daar wel aan liggen!

Yup, zit ook op HSA

[Janoz]

Op donderdag 06 juni 2002 11:02 schreef Bootje het volgende:

En natuurlijk bij bedrijf een entiteit die gelijk staat aan de primaire sleutel van Contactpersoon, dit is in bedrijf dan de foreign key.

Hij wil meerdere personen aan 1 bedrijf kunnen hangen. Bij persoon dus de ID van het bedrijf opslaan ipv bij het bedrijf de ID van de persoon opslaan.

[.GoO]

Op donderdag 06 juni 2002 11:06 schreef Janoz het volgende:

[..]

Hij wil meerdere personen aan 1 bedrijf kunnen hangen. Bij persoon dus de ID van het bedrijf opslaan ipv bij het bedrijf de ID van de persoon opslaan.

Lijkt me logisch..

Maar topicstarten is weg?

[Bootje]

Op donderdag 06 juni 2002 11:06 schreef Janoz het volgende:
[..]
Hij wil meerdere personen aan 1 bedrijf kunnen hangen. Bij persoon dus de ID van het bedrijf opslaan ipv bij het bedrijf de ID van de persoon opslaan.

True! Effe overheen gelezen.

[Scharnout]

Op donderdag 06 juni 2002 11:06 schreef Janoz het volgende:

[..]

Hij wil meerdere personen aan 1 bedrijf kunnen hangen. Bij persoon dus de ID van het bedrijf opslaan ipv bij het bedrijf de ID van de persoon opslaan.

Klopt! Dat was dus ook mijn plan. Ik maak eigenlijk altijd IDnr's aan voor bijna elke tabel. KvKnummer is namelijk bij filialen hetzelfde . Bij filialen is soms zelfs het BTW-nummer anders (staat er ipv .B.01 .B.02 ofzo - handig als je eigenlijk financiele pino bent ipv progger ) Dus voor mijn bedrijfstabel maak ik ook een nummer aan (soort klantnummer zeg maar).

Goed ... voornaamste reden dat ik het dus NIET ga doen is inderdaad dat je contactpersonen aan bedrijven kan hangen enz enz en dat je gewoon een moeilijk beheersbare tabel krijgt (zeer foutgevoelig).

Bedankt voor het meedenken!

[Bootje]

You're welcome!

Succes met je db!

[3o3]

normaliserend gezien is het het mooist met 3 tabelletjes natuurlijk, 2 voor de verschillende entiteiten bedrijf en persoon, en 1 relatietabel.
Maarja, tis maar een klein databaseje dus wattahell, zolang een persoon niet voor meer dan 1 berdijf werkt gaat dat prima met 2, vergeet inderdaad je primaire sleuteltjes niet.

[ATS]

Zoals iedereen hier aan aangeeft is splitsen de enige goede optie. Daar is, buiten de al genoemde redenen, nog een reden voor: Op deze manier ga je gegevens dubbel opslaan (de NAW gegevens), en dat is een bron van inconsitenties. Bovendien worden de queries veel ingewikkelder. Gewoon splitsen dus.

P.S. Een boek over databaseontwerp had je dat zo kunnen vertellen, in het hoofdstuk normalisatie.

[Scharnout]

Op donderdag 06 juni 2002 12:24 schreef ATS het volgende:
Zoals iedereen hier aan aangeeft is splitsen de enige goede optie. Daar is, buiten de al genoemde redenen, nog een reden voor: Op deze manier ga je gegevens dubbel opslaan (de NAW gegevens), en dat is een bron van inconsitenties. Bovendien worden de queries veel ingewikkelder. Gewoon splitsen dus.

P.S. Een boek over databaseontwerp had je dat zo kunnen vertellen, in het hoofdstuk normalisatie.

Zoals ik zelf al aangegeven had, zou ik ook voor die eerste optie gaan maar omdat ik vrij nieuw ben met dit alles (maar we al wel het schompes gelezen heb) wil ik af en toe nog wel confirmatie hebben over mijn keuzes .

Verder denk ik dat het redelijk uitgesloten is dat een contactpersoon voor 2 bedrijven werkt, vandaar dat ik maar 2 tabellen neem.

Bedankt nogmaals!

[Verwijderd]

Op donderdag 06 juni 2002 12:22 schreef 3o3 het volgende:
normaliserend gezien is het het mooist met 3 tabelletjes natuurlijk, 2 voor de verschillende entiteiten bedrijf en persoon, en 1 relatietabel.
Maarja, tis maar een klein databaseje dus wattahell, zolang een persoon niet voor meer dan 1 berdijf werkt gaat dat prima met 2, vergeet inderdaad je primaire sleuteltjes niet.

Zoals ik begrepen heb hierboven, heeft een contactpersoon maar 1 bedrijf en kan een bedrijf meerdere contactpersonen hebben. Een extra relatietabel is dus overbodig en neemt alleen maar nutteloze ruimte in beslag.....

[Scharnout]

Ok ... nu heb ik zelfs geen idee.

Mijn bedrijf handelt in verschillende soorten producten. Zeg maar ff computers en bloembollen . Dit gooi ik natuurlijk in een aparte tabel, maar waar link ik dit aan ... contactpersoon of bedrijf? want het is zeer goed mogelijk dat contactpersoon 1 de bloembollen doet en contactpersoon 2 de computers? Maar in de meeste gevallen doen ze allemaal hetzelfde. En waar geef ik aan of het een inkoop of verkoop persoon is (toevallig hebben wij een klant waar wij zowel inkopen als verkopen).

Als dat laatste geval er niet zou zijn, zou ik de inkoop/verkoop aan bedrijf koppelen en productsoort aan contactpersoon, maar ik neig nu om alles aan contactpersoon te hangen of moet ik hier slim programeren en binnen bedrijf ook een dezelfde dingen opnemen die default gelden als er niets bij contactpersoon is ingevuld.

Dit gaat mij ver boven de pet!

[Uiligheid]

Volgens mij moet je gewoon de volgende tabellen hebben:

Personen (zowel contactpersonen als andere)
Bedrijven
Producten

Bedrijven kunnen dan meerdere producten verkopen, ook contactpersonen kunnen meerdere producten vertegenwoordigen
Personen kunnen bij een bedrijf horen, of meer, of van bedrijf verwisselen.

is maar een idee.

[Bootje]

Bij contactpersoon kan je door een True/False aangeven of ze wel of niet inkopen/verkopen, je hoeft dan niet te keizen tussen een van beide maar kan allebei aanvinken.

Product zou ik aan bedrijf hangen. En je kan binnen Contactpersoon aangeven wat voor producten deze verkoopt.

[Scharnout]

Ok ... ik leg het niet goed uit. De volgende situaties kan ik volgens mij tegenkomen:

Wij kopen bij bedrijf printers in, maar tevens verkopen wij weer aan dat bedrijf computers. Er is maar 1 contactpersoon. Tevens hebben wij een bedrijf waar de printers bij inkopen. Ander contactpersoon. Beide bedrijven vallen in categorie computers, maar het eerste bedrijf valt ook in categorie printers. Er zit echter (marketingtechnisch en financieel) een heel groot verschil tussen inkoop en verkoop, dus wil ik dat ook splitsen.

Contactpersoon aan bedrijf koppelen lukt wel, maar dan?

Bedrijf 1
inkoop printers
verkoop computers
contactpersoon A

Bedrijf 2
Inkoop computers
contactpersoon B

en stel even:
bedrijf 3
inkoop printers
verkoop computers
contactpersoon C (voor Computers)
contactpersoon D (voor printers)

Volgens de wetten van accountantcy mag een inkoper nooit verkoper zijn, maar in kleine bedrijven (waar ik dus WEL mee te maken heb) is dat vaak toch zo. En vooral kleine bedrijven doen ook meerdere producten.

oh wacht .. volgens mij gaat er een lampje branden.

Zou ik het dan toch in een relatietabel en dan per contactpersoon aangeven of hij doet en wat hij met het poduct doen (bv inkoop en computers) en dan later bij bedrijf laten selecten welke waarden bij alle contactpersonen voorkomen? Volgens mij is dit dan de enige juiste oplossing.

Goh .. gaat wel makkelijk als je het helemaal uitwerkt