Springen naar inhoud


- - - - -

Probleem Bij Het Aanmaken Van Facturen

MS Access 2010 Relaties

  • Log in a.u.b. om te beantwoorden
Er zijn 58 reacties in dit onderwerp

#1 guest_MichaelDeBoey_*

guest_MichaelDeBoey_*
  • Gasten
    Laatst bezocht

Geplaatst op 24 april 2012 - 12:50

Hallo iedereen,

Zoals jullie reeds in vorige posts (Bestaat er een betere oplossing of is mijn methode geschikt?, Beste oplossing en Kan .mdb niet openen met Microsoft Access 2010) gezien hebben, ben ik al druk bezig geweest met de database voor het bijhouden van patiëntengegevens.
Hierbij is het ook de bedoeling dat de gebruiker op het einde van de maand een factuur voor elke patiënt kan afdrukken.
Nu gebeurd het ook dat de personeelsleden een factuur krijgen voor hun koffierekening (de bijdrage voor hun koffie tijdens de pauze).
Deze 2 soorten rekeningen zou ik dus opslaan in dezelfde tabel.
Ik heb het momenteel opgelost op de manier dat je kan bekijken in de afbeelding hieronder:
Bijlage  Relaties.png   104,09K   53 downloads
Zouden jullie dit ook zo doen of is er een betere manier?
Alvast bedankt!

UPDATE (23/05/2012 14:22): Vanaf nu kan je hier in bijlage steeds de nieuwste versie van mijn database (zowel in de 2000-, de 2003- als de 2007/2010-versie) terugvinden.

Bijgevoegde Bestanden



#2 guest_MichaelDeBoey_*

guest_MichaelDeBoey_*
  • Gasten
    Laatst bezocht

Geplaatst op 25 april 2012 - 08:00

Precies veel bekijk maar geen reactie :S

#3 pascalbianca

pascalbianca

    Webmaster/Admin

  • Webmaster
  • 4382 berichten
    Laatst bezocht 28 mei 2019 18:00
  • LocatieSusteren, Nederland, Midden Limburg.
Inzender

Geplaatst op 26 april 2012 - 06:34

Het ziet er zo wel goed uit.
Alleen je vraagt uiteraard of wij het ook zo zouden doen, maar dat is uiteraard weer een vraag die per persoon kan verschillen.
Het gaat er altijd om wat jij zelf het beste vind en waar je gevoel goed bij is :)
Wij hier in Limburg hebben daar een uitdrukking voor.
Als iemand in de Maas springt moet jij dan ook maar er achteraan springen ;)

#4 guest_MichaelDeBoey_*

guest_MichaelDeBoey_*
  • Gasten
    Laatst bezocht

Geplaatst op 26 april 2012 - 09:05

Daar heb je gelijk in, maar het probleem is juist dat ik denk dat het beter kan :D
Ik denk dat je de 2 velden "patientId" en "personeelsId" herleidt kunnen worden naar 1 veld.
En dit dan desnoods met een tussentabel.
Maar ik zou helemaal niet weten hoe ik dat zou moeten doen.

#5 guest_MichaelDeBoey_*

guest_MichaelDeBoey_*
  • Gasten
    Laatst bezocht

Geplaatst op 29 april 2012 - 19:24

Kan er echt niemand mij helpen? :S

#6 guest_MichaelDeBoey_*

guest_MichaelDeBoey_*
  • Gasten
    Laatst bezocht

Geplaatst op 09 mei 2012 - 12:56

Ok ik weet dat ik hopeloos aan het worden ben, maar volgens mij kan dit echt simpeler gedaan worden!
Want nu sla ik in het veld "personeelsId" een Id op en in het veld "patientId" een NULL-waarde op
Of omgekeerd.
Je slaat dus elke keer een NULL-waarde op die volgens mij vermeden kan worden...
Kan er echt niemand mij helpen? :S

#7 Jenny

Jenny

    Master Developer

  • Leden
  • PipPipPipPipPip
  • 558 berichten
    Laatst bezocht 02 apr 2017 22:13

Geplaatst op 10 mei 2012 - 09:10

Michael
NOFI hoor,maar ik vind je db ontwerp maar een rommeltje hoor
heb je wel een goede probleem analyse gedaan ?
maar op je vraag zou ik willen antwoorden met een vraag:
waarom zou je de facturen voor zowel de patienten als het personeel in 1 facturatie systeem willen opslaan ?
zijn patienten en personeel dan geen 2 verschillende entiteiten ?
ik heb nog een vraagje:
je hebt verschillende tabellen met slechts 2 velden,id en naam
geef daar eens wat uitleg over, zoals het veld type, de indexen,de reden dat die tabellen er zijn...alles wat er maar over te zeggen is

#8 guest_MichaelDeBoey_*

guest_MichaelDeBoey_*
  • Gasten
    Laatst bezocht

Geplaatst op 10 mei 2012 - 14:34

Jenny,

Bericht bekijkenJenny, op 10 mei 2012 - 09:10, zei:

heb je wel een goede probleem analyse gedaan ?
Tuurlijk heb ik goed nagedacht over wat het probleem is en over wat mijn programma zal moeten kunnen.

Bericht bekijkenJenny, op 10 mei 2012 - 09:10, zei:

waarom zou je de facturen voor zowel de patienten als het personeel in 1 facturatie systeem willen opslaan ?
zijn patienten en personeel dan geen 2 verschillende entiteiten ?
Zoals ik reeds vertelde wordt er maandelijks een factuur voor de patiënten aangemaakt.
Alsook worden er maandelijks voor de personeelsleden een factuur gemaakt voor hun koffierekening (een vast bedrag voor het verbruik van koffie).
Je moet dus telkens hetzelfde opslaan (zowel voor personeelsleden als voor patiënten) dus vind ik het logisch om er slechts 1 tabel voor te maken ipv 2 aparte tabellen...

Bericht bekijkenJenny, op 10 mei 2012 - 09:10, zei:

je hebt verschillende tabellen met slechts 2 velden,id en naam
geef daar eens wat uitleg over, zoals het veld type, de indexen,de reden dat die tabellen er zijn...alles wat er maar over te zeggen is
Het veld "id" is telkens van het type autonummering
Het veld "naam" is telkens van het type string

Hopelijk heb ik jouw vragen een beetje kunnen beantwoorden.
Mocht je nog vragen hebben, mag je die steeds stellen natuurlijk :D :P

Alvast bedankt voor de hulp!

#9 Jenny

Jenny

    Master Developer

  • Leden
  • PipPipPipPipPip
  • 558 berichten
    Laatst bezocht 02 apr 2017 22:13

Geplaatst op 10 mei 2012 - 22:08

Citeren

Tuurlijk heb ik goed nagedacht over wat het probleem is en over wat mijn programma zal moeten kunnen
dan heb je dus ook een goede probleem analyse op papier staan ?
het is voor iemand, die niet perfect op de hoogte is van het probleem domein, nogal moeilijk om je raad te geven he
(hint)

Citeren

Zoals ik reeds vertelde wordt er maandelijks een factuur voor de patiënten aangemaakt.
Alsook worden er maandelijks voor de personeelsleden een factuur gemaakt voor hun koffierekening (een vast bedrag
voor het verbruik van koffie).
Je moet dus telkens hetzelfde opslaan (zowel voor personeelsleden als voor patiënten) dus vind ik het logisch om er
slechts 1 tabel voor te maken ipv 2 aparte tabellen...
ja, als je dat logisch vindt, moet je maar met de gevolgen ervan leven he
maar ik dacht: patienten en personeel zijn 2 verschillende entiteiten
personeel betaald een vast bedrag per maand (dus hun facturen hebben eigenlijk geen detail nodig)
patienten hebben een heel gedetaileerde factuur nodig,tenslotte heeft elke patient toch meerdere en verschillende
behandelingen enz...
heb je al eens onderzoek gedaan hoe de betaling van de koffie gebeurd ?
persoonlijk ken ik geen enkel bedrijf dat hun personeel factureerd voor het koffie gebruik hoor
(gewoonlijk word dat door de personeeloversten geregeld)

Citeren

Het veld "id" is telkens van het type autonummering
Het veld "naam" is telkens van het type string
Hopelijk heb ik jouw vragen een beetje kunnen beantwoorden.
ik had wel wat meer uitleg over die velden verwacht hoor,maar goed:
ik veronderstel dat "id" de primary key van de tabel is,en dus foreign key in de patienten tabel
op dat veld staat dus een unieke index
ook veronderstel ik dat op "naam" ook een unieke index staat (logisch he)
waarom gebruik je 2 verschillende velden die allebei, en ieder voor zich, hetzelfde 'iets' volledig bepalen ?
als je bv het "id" niet gebruikt en "naam" de primary key maakt,spaar je een veld en een index uit
en bovendien wordt de patient tabel veel overzichtelijker
bv: we willen een patient tonen,dus met zijn handicap,verwijzer,mutualiteit
zoals het nu is hebben we daarvoor 4 tabellen en 3 joins nodig
gebruik je "naam" als primary key...heb je daarvoor 1 tabel en geen enkele join nodig

#10 RedThread

RedThread

    Beheerder VBIB

  • Beheerder
  • 3598 berichten
    Laatst bezocht 25 jul 2019 15:42
  • LocatieTongeren,Belgium.
Inzender

Geplaatst op 11 mei 2012 - 10:27

Een naam als primary key gebruiken vind ik nogal gevaarlijk hoor. Ik gebruik meestal een personeelsnummer of patiëntennummer, dat is zowieso uniek.
Wat als je patiënten heb met dezelfde naam/voornaam ?

Maar goed, iedereen geeft zijn eigen visie en ervaring. Het is aan Michaël om eruit te filteren wat hij het beste vind.

Wat dat koffiegebruik betreft... bij mijn huidige firma betalen we die helaas zelf hoor.
Zou nogal een serieuze rekening worden voor de firma als alle 350 bedienden gratis koffie konden slurpen ;)
Enkel het materiaal (koffiezet,filters,water,...) wordt gratis ter beschikking gesteld op elke afdeling.

Greetzzz
RedThread

#11 Jenny

Jenny

    Master Developer

  • Leden
  • PipPipPipPipPip
  • 558 berichten
    Laatst bezocht 02 apr 2017 22:13

Geplaatst op 11 mei 2012 - 12:41

Dag RedThread

Citeren

Een naam als primary key gebruiken vind ik nogal gevaarlijk hoor. Ik gebruik meestal een personeelsnummer of patiëntennummer, dat is zowieso uniek.
Wat als je patiënten heb met dezelfde naam/voornaam ?
en waar zeg ik (of suggereer ik zelfs maar) dat je de naam van een patient als primary key moet gebruiken ?

Citeren

Wat dat koffiegebruik betreft... bij mijn huidige firma betalen we die helaas zelf hoor.
en...factureerd uw huidige firma uw koffiegebruik aan u ?
vertel eens hoe de betaling van het koffiegebruik in uw huidige firma gebeurd
(zou wel eens heel leerzaam kunnen zijn voor Michael

#12 RedThread

RedThread

    Beheerder VBIB

  • Beheerder
  • 3598 berichten
    Laatst bezocht 25 jul 2019 15:42
  • LocatieTongeren,Belgium.
Inzender

Geplaatst op 11 mei 2012 - 13:16

als je bv het "id" niet gebruikt en "naam" de primary key maakt,spaar je een veld en een index uit
en bovendien wordt de patient tabel veel overzichtelijker


Ofwel mis ik de contex van je verhaal.

En ja, onze firma factureerd het koffieverbruik.
Iedereen duid aan wanneer hij een koffie verbruikt (gewoon streepje achter uw naam trekken op een A4 aan de koffiezet)
Deze wordt dan maandelijks opgehaald door een secretaresse en verwerkt, en wordt maandelijks afgetrokken van je loon.

#13 guest_MichaelDeBoey_*

guest_MichaelDeBoey_*
  • Gasten
    Laatst bezocht

Geplaatst op 11 mei 2012 - 14:39

Bericht bekijkenRedThread, op 11 mei 2012 - 10:27, zei:

Een naam als primary key gebruiken vind ik nogal gevaarlijk hoor. Ik gebruik meestal een personeelsnummer of patiëntennummer, dat is zowieso uniek.
Wat als je patiënten heb met dezelfde naam/voornaam ?
Zo ben ik idd ook van mening :D

Bericht bekijkenRedThread, op 11 mei 2012 - 10:27, zei:

Wat dat koffiegebruik betreft... bij mijn huidige firma betalen we die helaas zelf hoor.
Zou nogal een serieuze rekening worden voor de firma als alle 350 bedienden gratis koffie konden slurpen ;)
Enkel het materiaal (koffiezet,filters,water,...) wordt gratis ter beschikking gesteld op elke afdeling.

Bericht bekijkenRedThread, op 11 mei 2012 - 13:16, zei:

onze firma factureerd het koffieverbruik.
Iedereen duid aan wanneer hij een koffie verbruikt (gewoon streepje achter uw naam trekken op een A4 aan de koffiezet)
Deze wordt dan maandelijks opgehaald door een secretaresse en verwerkt, en wordt maandelijks afgetrokken van je loon.
In het bedrijf waarvoor ik de applicatie aan het maken ben gaat het idd ook zo te werk.
Maar ze trekken het niet van het loon af.
De boekhouding (in Gent) regelt het loon.
Het bedrijf zelf (in Sint-Niklaas) regelt de koffierekening.
Ze geven dan een factuur (eigenlijk gewoon een betalingsbewijsje) aan hun personeelsleden die dan hun rekening betalen.

Dus je hebt, zoals ik eerder al vermelde, 2 keer een factuur voor handen.
De ene keer voor een personeelslid, de andere keer voor een patiënt.
Maar op de manier dat ik het nu doe, sla ik telkens een NULL-waarde op terwijl het TOTAAL NIET nodig is...
Daarom denk ik dat er een betere oplossing zou zijn.
Alleen zou ik niet weten hoe dat moet :S

#14 Jenny

Jenny

    Master Developer

  • Leden
  • PipPipPipPipPip
  • 558 berichten
    Laatst bezocht 02 apr 2017 22:13

Geplaatst op 11 mei 2012 - 18:37

ja zeg jongens ,zeg mij dan toch eens WAAR ik zeg dat je de naam van de patienten als primary key moet gebruiken
ben ik dan de enige, die het plaatje dat Michael hier gezet heeft, bekeken heeft ?
ben ik de enige die gezien heeft dat er 6 tabellen zijn met elk slechts 2 velden (id en naam)
en kan er iemand mij uitleggen WAAROM dat id veld er is,en WAAROM het de primary key is
en in mijn vorige post ging het specifiek over de handicap,verwijzer en mutualit... tabellen
als je in die tabellen het naam veld de primary key maakt,en je wil een patienten kaart tonen dan heb je geen joins
naar die tabellen nodig
maak je het id veld primary key dan heb je naar alle 3 die tabellen joins nodig
tenzij je er natuurlijk van uitgaat dat de gebruiker niet hoeft te weten wat de naam is
(arme gebruiker ? ja,maar de programmeur heeft niet nagedacht he)

#15 RedThread

RedThread

    Beheerder VBIB

  • Beheerder
  • 3598 berichten
    Laatst bezocht 25 jul 2019 15:42
  • LocatieTongeren,Belgium.
Inzender

Geplaatst op 11 mei 2012 - 19:55

Bericht bekijkenJenny, op 10 mei 2012 - 22:08, zei:

ik veronderstel dat "id" de primary key van de tabel is,en dus foreign key in de patienten tabel
op dat veld staat dus een unieke index
ook veronderstel ik dat op "naam" ook een unieke index staat (logisch he)
waarom gebruik je 2 verschillende velden die allebei, en ieder voor zich, hetzelfde 'iets' volledig bepalen ?
als je bv het "id" niet gebruikt en "naam" de primary key maakt,spaar je een veld en een index uit
en bovendien wordt de patient tabel veel overzichtelijker
bv: we willen een patient tonen,dus met zijn handicap,verwijzer,mutualiteit
zoals het nu is hebben we daarvoor 4 tabellen en 3 joins nodig
gebruik je "naam" als primary key...heb je daarvoor 1 tabel en geen enkele join nodig

Wat moet ik daar anders uit opmaken Jenny ?

En ik zou het appreciëren moest je die cynische opmerkingen achterwege laten.

mvg,
RedThread

#16 Jenny

Jenny

    Master Developer

  • Leden
  • PipPipPipPipPip
  • 558 berichten
    Laatst bezocht 02 apr 2017 22:13

Geplaatst op 12 mei 2012 - 00:02

Citeren

Jenny, op 10 May 2012 - 08:10, zei:
je hebt verschillende tabellen met slechts 2 velden,id en naam
geef daar eens wat uitleg over, zoals het veld type, de indexen,de reden dat die tabellen er zijn...alles wat er maar over te
zeggen is
ik herhaal:
je hebt verschillende tabellen met slechts 2 velden,id en naam
dit slaat klaar en duidelijk NIET op de patient tabel he
het antwoord van Michael:

Citeren

Het veld "id" is telkens van het type autonummering
Het veld "naam" is telkens van het type string
afgezien van het feit dat Michael NIET op mijn vragen geantwoord heeft(slechts op 1)
slaat dit klaar en duidelijk op die verschillende tabellen die slechts 2 velden hebben he
mijn reaktie daarop:

Citeren

ik had wel wat meer uitleg over die velden verwacht hoor,maar goed:
ik veronderstel dat "id" de primary key van de tabel is,en dus foreign key in de patienten tabel
dit slaat toch weer klaar en duidelijk op die verschillende tabellen die slechts 2 velden hebben he
trouwens als U dat interpreteerd als slaande op de patienten tabel
leg mij dan eens uit hoe een veld de primary key van een tabel kan zijn en terzelfder tijd een foreign key in dezelfde tabel ???

in dezelfde post door mij:

Citeren

waarom gebruik je 2 verschillende velden die allebei, en ieder voor zich, hetzelfde 'iets' volledig bepalen ?
dit kan toch onmogelijk op de patienten tabel slaan he
sinds wanneer is de naam van een persoon volledig bepalend voor die persoon ???
in dezelfde post door mij:

Citeren

als je bv het "id" niet gebruikt en "naam" de primary key maakt,spaar je een veld en een index uit
dit kan toch ook onmogelijk geinterpreteerd worden als slaande op de patienten tabel he
wie zal het ooit in zijn hoofd halen om te denken dat de naam van een mens, die mens ondubbelzinnig identificeerd
in dezelfde post door mij:

Citeren

en bovendien wordt de patient tabel veel overzichtelijker
moest je even nagedacht hebben dan had je begrepen waarom dat de patienten tabel overzichtelijker maakt
maar ik zal het eens nog duidelijker uitleggen,ik zal 1 van die drie tabellen gebruiken waarvoor ik expliciet verwijs in die post

Citeren

bv: we willen een patient tonen,dus met zijn handicap,verwijzer,mutualiteit
zoals het nu is hebben we daarvoor 4 tabellen en 3 joins nodig
gebruik je "naam" als primary key...heb je daarvoor 1 tabel en geen enkele join nodig
nemen we tabel mutualiteit als voorbeeld, met een record als bv:
ID, Naam
12, Bond Moyson
dan staat er in de patienten tabel 1 of meerdere records met in het veld 'mutualiteitid' een 12
en dan moet de arme gebruiker maar weten dat die 12 op 'Bond Moyson' slaat
als je dat de arme gebruiker nu wil besparen heb je een join nodig tussen de patienten tabel en de mutualiteit tabel
maar:
als wij in de mutualiteit tabel het id veld verwijderen en "Naam" de primary key maken
dan staat in diezelfde  1 of meerdere records van de patienten tabel in het veld 'mutualiteitid'>>>"Bond Moyson"
en de gelukkige gebruiker hoefd niet meer te onthouden dat 12 op "Bond Moyson"
en er is een veld en een index minder nodig in de mutualiteit tabel
uiteraard zal het veld 'mutualiteitid' in de patienten tabel meer opslag ruimte vragen
(de string "Bond Moyson" heeft meer opslag ruimte nodig dan de integer 12)
idem dito voor de handicap en verwijzer tabellen

Michael:
als je dan toch die 2 velden in de factuur tabel door 1 veld wil vervangen:
het ID veld van je personeel tabel geef je een bepaalde range (bv van 1.000.000 tot 2.000.000)
en het ID veld van je patient veld geef je een andere range (bv > 2.000.000)
en nu kan je program gemakkelijk weten of een factuur voor een patient of een personeellid is

#17 Jenny

Jenny

    Master Developer

  • Leden
  • PipPipPipPipPip
  • 558 berichten
    Laatst bezocht 02 apr 2017 22:13

Geplaatst op 12 mei 2012 - 00:12

Redthread:
En ik zou het appreciëren moest je die cynische opmerkingen achterwege laten.
ok, kan ik begrijpen

En ik zou het appreciëren, als je op een post van mij opmerkingen hebt, eerst goed te lezen wat er staat
ik zal maar denken dat je niet naar het plaatje, dat Michael hier gepost heeft, gekeken hebt,en daarom wat er staat verkeerd geinterprteerd hebt

#18 pascalbianca

pascalbianca

    Webmaster/Admin

  • Webmaster
  • 4382 berichten
    Laatst bezocht 28 mei 2019 18:00
  • LocatieSusteren, Nederland, Midden Limburg.
Inzender

Geplaatst op 12 mei 2012 - 07:23

Onderwerp.

Beste mensen,

Kunnen we het a.u.b. ontopic houden ,anders ben ik genoodzaakt deze topic op slot te gooien ten kosten van MichaelDeBoey en dat zou spijtig zijn voor hem.

Alvast bedankt.



#19 guest_MichaelDeBoey_*

guest_MichaelDeBoey_*
  • Gasten
    Laatst bezocht

Geplaatst op 12 mei 2012 - 17:55

Beste Jenny,

Zoals ik in mijn eerste bericht schreef ben ik bezig met het maken van een programma in Visual Basic en is het dus niet de bedoeling Access te gebruiken, enkel en alleen als databasemodel.

Ik hoop dat hierbij al meerdere vragen zijn opgelost.

#20 guest_MichaelDeBoey_*

guest_MichaelDeBoey_*
  • Gasten
    Laatst bezocht

Geplaatst op 12 mei 2012 - 18:01

Maar we zijn dus nog steeds niet verder met mijn vraag :S

Bericht bekijkenJenny, op 12 mei 2012 - 00:02, zei:

als je dan toch die 2 velden in de factuur tabel door 1 veld wil vervangen:
het ID veld van je personeel tabel geef je een bepaalde range (bv van 1.000.000 tot 2.000.000)
en het ID veld van je patient veld geef je een andere range (bv > 2.000.000)
en nu kan je program gemakkelijk weten of een factuur voor een patient of een personeellid is
Dan limiteer je jezelf tot een maximum van 1 miljoen patiënten, wat ook weer niet de bedoeling is.
Welke range je ook geeft aan beide Id's, je limiteert jezelf altijd.
En de bedoeling van een programma als deze is dat het in principe eeuwig kan blijven gebruikt worden zonder enige aanpassing.
Want als je een limiet instelt, kan het altijd zijn dat je toevallig een volgende patiënt hebt met een id dat net boven de limiet zit.
En hoe ga je dat dan oplossen?
Limiteren is nooit een goed idee...

#21 Jenny

Jenny

    Master Developer

  • Leden
  • PipPipPipPipPip
  • 558 berichten
    Laatst bezocht 02 apr 2017 22:13

Geplaatst op 14 mei 2012 - 14:50

@Michael

Citeren

Dan limiteer je jezelf tot een maximum van 1 miljoen patiënten, wat ook weer niet de bedoeling is.
als je bedoelt 1 miljoen personeelsleden heb je gelijk
als 1 miljoen mogelijke personeelsleden niet genoeg zijn geef ze dan een range van 2 miljoen of 20 miljoen of whatever he
en het voorbeeld dat ik je gegeven heb voor de patienten (>2.000.000)
daarbij limiteer je het aantal mogelijke patienten tot meer dan de helft van de wereldbevolking
(de totale wereldbevolking word op dit moment geschat op 7 miljard)

Citeren

Welke range je ook geeft aan beide Id's, je limiteert jezelf altijd.
En de bedoeling van een programma als deze is dat het in principe eeuwig kan blijven gebruikt worden zonder enige aanpassing.
Want als je een limiet instelt, kan het altijd zijn dat je toevallig een volgende patiënt hebt met een id dat net boven de limiet
zit.
En hoe ga je dat dan oplossen?
Limiteren is nooit een goed idee...
"Limiteren is nooit een goed idee..."
dat ben ik volkomen met je eens
MAAR...waarom limiteer jij jezelf dan in elke tabel in je database ? (autonummers he)
ik heb 2 heel goede oplossingen voor je probleem gegeven
je wil ze niet gebruiken, ok hoor,dat is jouw keuze
Maar,je weet toch wat de oorzaak van je probleem is he
de oorzaak is dat er geen enkele manier is om te weten of een id (autonummer dus)
van een patient of van personeel afkomstig is (tenzij deze id's verschillende ranges hebben)
en wie heeft dat probleem gecreeerd ?

@PascalBianca

Citeren

Onderwerp.
Beste mensen,
Kunnen we het a.u.b. ontopic houden ,anders ben ik genoodzaakt deze topic op slot te gooien ten kosten MichaelDeBoey en dat zou
spijtig zijn voor hem.
Alvast bedankt.
lief van u om dit topic ten bate van MichaelDeBoey open te houden
maar...waarom krijgt de enige die hem heeft willen helpen dan een ban ????
@allen
omdat oa deze vraag door niemand beantwoord is, zal ik het maar zelf doen he

Citeren

leg mij dan eens uit hoe een veld de primary key van een tabel kan zijn en terzelfder tijd een foreign key in dezelfde tabel ???
...als de tabel aan zichzelf refereerd he
Groetjes he
jenny
juist, ja, jenny dus, en geef JerryMac nu ook maar een ban

#22 RedThread

RedThread

    Beheerder VBIB

  • Beheerder
  • 3598 berichten
    Laatst bezocht 25 jul 2019 15:42
  • LocatieTongeren,Belgium.
Inzender

Geplaatst op 14 mei 2012 - 15:37

Jenny,

De enige reden voor je ban (van 1 week) is zowat je constante regelmaat met grove uitlatingen en manier van reageren.
Ik heb geen probleem met discussies, maar ze moet wel met respect voor eenieders mening worden gevoerd en gelet op het niveau van kennis. (zie richtlijnen)
Op geen enkel moment is er respectloos gereageerd naar jouw toe, dan verwachten we hetzelfde van jou.


Citeren

NOFI hoor,maar ik vind je db ontwerp maar een rommeltje hoor
ja, als je dat logisch vindt, moet je maar met de gevolgen ervan leven he
ben ik dan de enige, die het plaatje dat Michael hier gezet heeft, bekeken heeft ?
arme gebruiker ? ja,maar de programmeur heeft niet nagedacht he
moest je even nagedacht hebben
maar ik zal het eens nog duidelijker uitleggen
en dan moet de arme gebruiker maar weten
En ik zou het appreciëren, als je op een post van mij opmerkingen hebt, eerst goed te lezen wat er staat
ik zal maar denken dat je niet naar het plaatje, dat Michael hier gepost heeft, gekeken hebt

Je ban zit er komende zaterdag op zoals vermeld in je mail, je dubbele account zal worden gewist.

RedThread
VBiB

#23 Hypenate

Hypenate

    Guru Developer

  • Leden
  • PipPipPipPipPipPip
  • 1228 berichten
    Laatst bezocht 15 mei 2019 21:27
Inzender

Geplaatst op 14 mei 2012 - 17:48

'k Lees veel gezever hier, dus het zou kunnen dat het reeds gezegd is:

Ik zou de tabellen gescheiden houden (performantie > normalisatie).
Overlaatst hetzelfde probleem gehad, en het de tabel terug uit mekaar gehaald (de-normalisatie) en in 2 tabellen verveeld, omdat het overzicht totaal zoek was.

#24 guest_MichaelDeBoey_*

guest_MichaelDeBoey_*
  • Gasten
    Laatst bezocht

Geplaatst op 15 mei 2012 - 02:37

Bericht bekijkenJenny, op 14 mei 2012 - 14:50, zei:

MAAR...waarom limiteer jij jezelf dan in elke tabel in je database ? (autonummers he)
Volgens mij is een autonummer nog steeds geen limiet op het aantal records zetten.
Het is gewoon een makkelijke manier om tussen de mogelijk duizenden records snel het juiste record te vinden...

Bericht bekijkenJenny, op 14 mei 2012 - 14:50, zei:

...als de tabel aan zichzelf refereerd he
Bij welke tabel refereer ik naar de eigen tabel?
Zoals je zegt is het idd dom om het id van een bepaald record te gebruiken als foreign key in datzelfde record, maar dat gebeurd toch nergens, dus ik snap echt niet wat je bedoeld...

Bericht bekijkenHypenate, op 14 mei 2012 - 17:48, zei:

Ik zou de tabellen gescheiden houden (performantie > normalisatie).
Overlaatst hetzelfde probleem gehad, en het de tabel terug uit mekaar gehaald (de-normalisatie) en in 2 tabellen verveeld, omdat het overzicht totaal zoek was.
Kan je dat eens nader uitleggen aan de hand van mijn voorbeeld aub?

#25 Hypenate

Hypenate

    Guru Developer

  • Leden
  • PipPipPipPipPipPip
  • 1228 berichten
    Laatst bezocht 15 mei 2019 21:27
Inzender

Geplaatst op 15 mei 2012 - 08:01

Autonummering kan zover gaan als het maar wil, momenteel zit ik ergens in een 5.000 records, alles nog ok :).

Er valt eigenlijk weinig over te zeggen, je zou "patientId" en "personeelsId" samen voegen, maar dan wel 1 'tussentabel' maken. Je kan blijven normaliseren, maar of dat wijs is, dat hangt van jou af.
Uit mijn eigen ervaring zou'k zeggen laat het zoals het is.
Wat je wel kan doen, is in je programma een klasse Persoon maken en dan die klasse overerven in een klasse Patient en klasse Personeel.

#26 guest_MichaelDeBoey_*

guest_MichaelDeBoey_*
  • Gasten
    Laatst bezocht

Geplaatst op 15 mei 2012 - 10:40

Bericht bekijkenHypenate, op 15 mei 2012 - 08:01, zei:

Autonummering kan zover gaan als het maar wil, momenteel zit ik ergens in een 5.000 records, alles nog ok :).
Ja dat weet ik wel :D
Autonummering zou oneindig door kunnen gaan he :D

Bericht bekijkenHypenate, op 15 mei 2012 - 08:01, zei:

Er valt eigenlijk weinig over te zeggen, je zou "patientId" en "personeelsId" samen voegen, maar dan wel 1 'tussentabel' maken. Je kan blijven normaliseren, maar of dat wijs is, dat hangt van jou af.
Uit mijn eigen ervaring zou'k zeggen laat het zoals het is.
Een tussentabel zou niet percé moeten.
Ik denk gewoon dat het nu simpeler kan en mij opslag kan besparen.
Aangezien facturen iets zijn wat er veel in de database gaan staan is het dus wel aangeraden om extra opslag vrij te maken.
Het zal niet zo HEEL veel zijn, maar ik heb altijd geleerd dat je zo weinig mogelijk opslag moet gebruiken dus...

Bericht bekijkenHypenate, op 15 mei 2012 - 08:01, zei:

Wat je wel kan doen, is in je programma een klasse Persoon maken en dan die klasse overerven in een klasse Patient en klasse Personeel.
Dat is natuurlijk een mogelijkheid voor in het programma, maar ik zoek een oplossing op databaseniveau dus... :D

#27 RedThread

RedThread

    Beheerder VBIB

  • Beheerder
  • 3598 berichten
    Laatst bezocht 25 jul 2019 15:42
  • LocatieTongeren,Belgium.
Inzender

Geplaatst op 15 mei 2012 - 13:26

Dus Michael, even opsommen :

1- Data opslaan in één tabel met als gevolg een NULL
2- 2 verschillende factuur tabellen maken patiënten/personeel
3- aparte nummer range (personeel/patienten) binnen één factuur tabel gebruiken
4- Tussentabel


Mijn persoonlijke voorkeur gaat naar oplossing 2, geen problemen met overlappende nummers, NULL waardes etc...
Plus naar uitbreiding toe, als je later velden moet toevoegen die specifiek zijn voor één doelgroep (bv personeel), dan is dat netjes gescheiden en kan je dat zonder problemen doen.


Greetzzz
RedThread.

#28 Jenny

Jenny

    Master Developer

  • Leden
  • PipPipPipPipPip
  • 558 berichten
    Laatst bezocht 02 apr 2017 22:13

Geplaatst op 20 mei 2012 - 09:59

een tussentabel zou de slechtste oplossing zijn
bedenk ook dat een range niet noodzakelijk numeriek moet zijn

#29 Hypenate

Hypenate

    Guru Developer

  • Leden
  • PipPipPipPipPipPip
  • 1228 berichten
    Laatst bezocht 15 mei 2019 21:27
Inzender

Geplaatst op 20 mei 2012 - 11:08

Da's dus 3 - 0 :P

#30 guest_chrissie1_*

guest_chrissie1_*
  • Gasten
    Laatst bezocht

Geplaatst op 20 mei 2012 - 11:29

Citeren

En de bedoeling van een programma als deze is dat het in principe eeuwig kan blijven gebruikt worden zonder enige aanpassing.

De praktijk leert dat dit niet echt een optie is. Maar een mens kan altijd dromen.

En laat ons niet vergeten dat access een 2GB file limiet heeft.

Mijn advies. Doe het éénvoudigste wat werkt voor uw geval en doe dat goed je kan daarna altijd nog aanpassen.





Ook met taq MS Access 2010, Relaties voorzien

0 gebruiker(s) lezen dit onderwerp

0 lid(leden), 0 bezoeker(s), 0 anonieme gebruikers

Inloggen


Untitled 1

Met dank aan Jürgen voor de jarenlange inzet van visualbasic.be (anno dec 2000)
Met dank aan Mike en Ronneke voor de jarenlange inzet van vbib.be (anno dec 2010)
Met dank aan PascalBianca voor de jarenlange inzet van vbib.be (anno dec 2016)