[SQL]Is dit mogelijk met 1 query en zo ja hoe?

[a3konijn]

Ik wil van een aantal items bijhouden wie het gekocht heeft en wie er allemaal in medelen.

Ik heb daarvoor de volgende tabellen die ik alvast voorzien heb van wat inhoud

code:

________________________________________________
#Persons#: PersonID    Name
          1    A
          2    B
          3    C
          4    D
________________________________________________
#Items#:  ItemID   PersonID  Price
          1   1   12.5
          2   2   10.90
          3   1    0.35
________________________________________________
#Items_Persons#   Id   ItemID     PersonID
             0     1        1
             1     1        2
             2     1        3
             3     1        4
             4     2        1
             5     2        2
             6     2        3
             7     3        1
             8     3        4

Dus Persoon met Naam B heeft in dit voorbeeld dus
Item met id 2 gekocht (zoals blijkt uit tabel items) ter waarde van 10.90 Dit item was eveneens bestemd voor personen A en C zoals blijkt uit Items_Persons. Dus deze delen daarin mee. Hierdoor hebben A en C beiden een schuld van 10.90/3 = 3.63 bij B en staat B (10.90- 3.63)=7.27 in de plus.

Nu wil ik dus proberen om het liefst met 1 select query uit te rekenen wat iemand moet betalen aan anderen. Als je daarvan met de volgende query:

SELECT sum(Price) FROM items WHERE PersonID = persoonid;

het bedrag aftrekt wat iemand zelf uitgegeven hebt kan je z'n saldo uitrekenen.

Hiervoor moet het volgende gebeuren:
Voor ieder itemid waaraan zijn personid gekoppeld is in de tabel items_persons moet er gekeken worden hoeveel andere personen erin meedeelden. De prijs die bij het item hoort delen door dit aantal personen en dit optellen bij zijn totaal.

Er zal dus iets in moeten komen van:
SELECT SUM(Price) FROM items, items_persons WHERE items_persons.PersonID = personid AND items_persons.ItemID = items.itemid;
(Hiermee heb je dus de som van alles waaraan hij meebetaald, maar dat klopt niet)

gecombineerd met:
SELECT COUNT(personid) FROM items_persons WHERE items_persons.PersonID = personid AND ItemID = itemid;
(Hier heb je van een item het aantal mensen wat eraan meebetaald)

Er zit hier dus een overlap in het itemid.
Wie helpt me op weg??

EDIT: eventjes tabellen gerangschikt. EN oh ja, ik wil het met PHP en mysql oplossen, maar echt relevent is dat niet.

[Verwijderd]

kan je even die tabellen wat beter schikken dat het wat duidelijker is aub?

Er zit hier dus een overlap in het itemid.
Wie helpt me op weg??

wat bedoel je? ik snap ook het concept niet goed, kan je dat wat duidelijker uitleggen misschien?

Die queries die je hebt opgeschreven, komen die uit je code, of heb je die vlug opgeschreven, want in dat eerste geval zal je wsl $ moeten gebruiken om aan te duiden dat personid een variabele is, en bij itemid ook...

[a3konijn]

Op maandag 21 januari 2002 21:31 schreef Jppr het volgende:
kan je even die tabellen wat beter schikken dat het wat duidelijker is aub?

Heb ik gedaan

wat bedoel je? ik snap ook het concept niet goed, kan je dat wat duidelijker uitleggen misschien?

In ons studentenhuis hadden we altijd een programma waarin we bijhielden wie wat aangeschaft had en wie er allemaal in de kosten daarvan meedeelden. Dat programma werkt niet meer onder XP en heeft ook problemen met jaartallen groter dan 31-12-2001. Dus ik dacht ik maak wel ff een database aan met wat php erbij.
Nou is het toevoegen van items geen probleem; gewoon met een formpje die in de tabel items post wie wat gekocht heeft en wat het koste en nog wat info en in de tabel items_persons post voor wie het allemaal bedoelt is.
Nu wil ik de gebruikers echter ook in een opslag kunnen laten zien wat ze aan schuld staan.

Dit is dus het bedrag dat ze zelf uitgegeven hebben gegeven - (ditzelfde bedrag / aantal mensen dat daarin meedelen) - (de prijs van alle items waarin ze meedelen maar niet zelf aangeschaft hebben / alle mensen die hierin meedelen)

Die queries die je hebt opgeschreven, komen die uit je code, of heb je die vlug opgeschreven, want in dat eerste geval zal je wsl $ moeten gebruiken om aan te duiden dat personid een variabele is, en bij itemid ook...

Nee heb ik vlug opgeschreven. Vind het knap dat je weet dat ik php wil gaan gebruiken want dat stond in eerste instantie niet in m'n tekst. (Bij deze trouwens toegevoegd)

[dusty]

Je model klopt gewoonweg niet.

Persoon B koopt het,
persoon A en C staan dus in de schuld, Nu betaald alleen Persoon A, Hoe hou JIJ dat bij?

[Bananeman]

Op dinsdag 22 januari 2002 09:23 schreef dusty het volgende:
Je model klopt gewoonweg niet.

Persoon B koopt het,
persoon A en C staan dus in de schuld, Nu betaald alleen Persoon A, Hoe hou JIJ dat bij?

Klopt, maar dat vergt een eenvoudige uitbreiding van zijn datamodel. Is verder niet relevenant voor het probleem. Ik heb alleen geen zin om daar nu naar te kijken...

[Verwijderd]

haha '#items#' IS al Items_Persons. ipv, dat hij daar de 'ID' uit 'Items_Persons' gebruikt...

[Gerco]

-- Hier stond iets doms --

[dusty]

Op dinsdag 22 januari 2002 09:37 schreef Bananeman2002 het volgende:
[..]
Klopt, maar dat vergt een eenvoudige uitbreiding van zijn datamodel. Is verder niet relevenant voor het probleem. Ik heb alleen geen zin om daar nu naar te kijken...

'eenvoudige uitbreiding' het heeft alleen al invloed op zijn huidige tabellen, dus zo eenvoudig is het niet als er al informatie in zou staan.

[dusty]

Op dinsdag 22 januari 2002 09:47 schreef Otis het volgende:
haha '#items#' IS al Items_Persons. ipv, dat hij daar de 'ID' uit 'Items_Persons' gebruikt...

Er hoort op het moment eigenlijk geen ID in de items_persons tabel voor te komen

[Bananeman]

Op dinsdag 22 januari 2002 09:54 schreef dusty het volgende:

[..]

'eenvoudige uitbreiding' het heeft alleen al invloed op zijn huidige tabellen, dus zo eenvoudig is het niet als er al informatie in zou staan.

Hij moet zaken toevoegen, absoluut, maar hij hoeft niets te wijzigen aan de huidige velden. Dus je hebt gelijk dat het model niet compleet is, maar dat is voor het probleem dat aan de orde is niet relevant.

[Bananeman]

Op dinsdag 22 januari 2002 09:56 schreef dusty het volgende:

[..]

Er hoort op het moment eigenlijk geen ID in de items_persons tabel voor te komen

dat id is idd overbodig. als hij later zaken wil registreren, zoals het door een persoon reeds betaalde bedrag voor een item, dan vormen PersonId en ItemId samen de key..

[Verwijderd]

Leuke uitdaging. 'k Vraag me af waarom je dit in 1 query zou willen doen. Waarschijnlijk is het veel sneller gerealiseerd in meerdere queries.

[a3konijn]

Op dinsdag 22 januari 2002 09:23 schreef dusty het volgende:
Je model klopt gewoonweg niet.

Persoon B koopt het,
persoon A en C staan dus in de schuld, Nu betaald alleen Persoon A, Hoe hou JIJ dat bij?

Model klopt wel. Items_Persons houd bij voor wie het item allemaal bestemd is. Het kan nl. ook voorkomen dat iemand een item aanschaft voor iemand anders terwijl het niet voor de koper zelf bestemd is.
Dan wordt aan items de personID en price toegevoegd
en aan itmes_persons het itemdid uit items en de personid voor wie het bestemd was.

[a3konijn]

[sorry dubbelpost]

[a3konijn]

Op dinsdag 22 januari 2002 10:11 schreef Bananeman2002 het volgende:

[..]

dat id is idd overbodig. als hij later zaken wil registreren, zoals het door een persoon reeds betaalde bedrag voor een item, dan vormen PersonId en ItemId samen de key..

Klopt hiermee ben ik het volledig eens. Maar dit heeft verder geen invloed en maakt het model niet minder kloppend.

Op dinsdag 22 januari 2002 09:47 schreef Otis het volgende:
haha '#items#' IS al Items_Persons. ipv, dat hij daar de 'ID' uit 'Items_Persons' gebruikt...

Model klopt wel. Items_Persons houd bij voor wie het item allemaal bestemd is. Het kan nl. ook voorkomen dat iemand een item aanschaft voor iemand anders terwijl het niet voor de koper zelf bestemd is.
Dan wordt aan items de personID en price toegevoegd
en aan itmes_persons het itemdid uit items en de personid voor wie het bestemd was.

Leuke uitdaging. 'k Vraag me af waarom je dit in 1 query zou willen doen. Waarschijnlijk is het veel sneller gerealiseerd in meerdere queries.

Vind ik ook Ik zeg alleen niet dat het in een query moet. Ik vroeg me alleen af of dat mogelijk was. Mysql kan nl. best wel wat zaken die met standaard SQL-SELECT-queries niet kunnen.

[dusty]

Op dinsdag 22 januari 2002 10:56 schreef a3konijn het volgende:
[..]
Model klopt wel.
[..]

Dan blijf je lekker dit model gebruiken. Blijf je lekker hetzelfde tegen je data aankijken dat je bent gewend, vooral niet verder kijken of er betere mogelijkheden zijn, of je het misschien anders kan oplossen wat een betere resultaat gaat geven, wat beter uit te bereiden is.

Immers zal het ook nooit voorkomen dat persoon A en C samen product "2" kopen terwijl alleen persoon B ervoor hoort te betalen, dat hoeft blijkbaar nooit in de toekomst te kunnen.

[a3konijn]

Op dinsdag 22 januari 2002 11:20 schreef dusty het volgende:

[..]

Dan blijf je lekker dit model gebruiken. Blijf je lekker hetzelfde tegen je data aankijken dat je bent gewend, vooral niet verder kijken of er betere mogelijkheden zijn, of je het misschien anders kan oplossen wat een betere resultaat gaat geven, wat beter uit te bereiden is.

Immers zal het ook nooit voorkomen dat persoon A en C samen product "2" kopen terwijl alleen persoon B ervoor hoort te betalen, dat hoeft blijkbaar nooit in de toekomst te kunnen.

[quote]

Ok ok, laat ik dan zo zeggen dat het model voldoet voor wat ik erin op wil slaan. Het klopt dat het nu niet mogelijk is om op te slaan dat 2 mensen 1 item gekocht hebben. Alleen dat is ook helemaal niet nodig. Zoals je ergens hierboven kan lezen is het bedoelt voor in een studentenhuis waar mensen zaken met elkaar willen verrekenen.

Wat wel mogelijk is is dat persoon A iets koopt alleen voor B. En indien A en B iets kopen voor C, dan is het vast een cadeautje en zo niet, dan slaan A en B toch ieder hun aandeel op en berekenen dat door aan C. Kost hooguit een extra regel in de database.

Maar er is tot nu toe blijkbaar niemand die een aanzet tot een oplossing heeft??

P.S. Ik wil niet koppig zijn ofzo, maar naar mijn idee is m'n model gewoon goed. Ok er worden natuurlijk ook nog datums etc aan toegevoegd, maar dat is hier niet relevant. En iedereen komt iedere keer met combinaties die niet opgeslagen zouden kunnen worden, maar als ze goed kijken zien ze dat dat dus wel degelijk mogelijk is. Afgezien dan van bovengenoemd item. Alleen dat is in 2 regels ook op te lossen.

[dusty]

Op dinsdag 22 januari 2002 13:22 schreef a3konijn het volgende:
P.S. Ik wil niet koppig zijn ofzo, maar naar mijn idee is m'n model gewoon goed. Ok er worden natuurlijk ook nog datums etc aan toegevoegd, maar dat is hier niet relevant. En iedereen komt iedere keer met combinaties die niet opgeslagen zouden kunnen worden, maar als ze goed kijken zien ze dat dat dus wel degelijk mogelijk is. Afgezien dan van bovengenoemd item. Alleen dat is in 2 regels ook op te lossen.

Ai...

komt ie weer:

code:

MijnTabel
----------
SpecialID int not null, (PK)
VolgID int,
Value varchar(veel)

Ik kan ook ALLES maken met deze tabel, Betekent dat deze datamodel ook goed is voor elke vraag ?

[a3konijn]

:'(:'(:'(:'(:'(:'(:'(

Dusty --> Jij denkt dat ik gek ben ofzo?? Volgens mij heb jij gewoon niet goed gelezen wat mijn bedoeling is. Maar omdat ik door jou ook aan mijzelf ging twijfelen heb ik de kwestie waar wij nu over twisten ook voorgelegd aan een IT-er op mijn werk die menig cursus over database modellen etc. heeft gevolgd dus hiervan wel degelijk op de hoogte is.

Hij had als enige commentaar dat je normaal gezien ook een tabel zou maken met daarin het itemid en de bijbehorende prijs, maar omdat ieder item in de tabel toch een unieke prijs zal hebben was mijn oplossing ook goed.

Maar nog een keertje een poging dan om mijn bedoeling uit te leggen:

In een studentenhuis waar 4 personen wonen wordt er in wisselbeurt gekookt en er worden ook andere artikelen aangeschaft die voor algemeen gebruik zijn. Zodoende moet er dus opgeslagen worden wie van de 4 personen iets aangeschaft heeft (dit kan een pak wc-rollen zijn, maar dus ook een complete maaltijd, vandaar dat een item bijna altijd een unieke prijs zal hebben) wat de prijs daarvan was en voor wie dat allemaal bestemd was. Het kan hierbij voorkomen dat een persoon iets koopt voor iemand anders dus dat hij het zeg maar voorschiet.

Dus daarom:

Een tabel waarin de personen opgeslagen worden met een uniek id:
CREATE TABLE Persons
(
PersonID int(3) NOT NULL auto_increment,
Name varchar(20) ,
PRIMARY KEY (PersonID)
);
en een tabel waarin opgeslagen wordt wie iets aangeschaft heeft voor meerdere mensen en wat dat koste:
CREATE TABLE Items
{
ItemID int(3) NOT NULL auto_increment,
PersonID int(3),
Price float(5),
PRIMARY KEY (ItemID)
);

en een lijst waarin opgeslagen wordt voor wie het item allemaal bestemd was:
CREATE TABLE Items_Persons
{
ItemID int(3),
PersonID int(3),
);

En zodoende gaf ik als voorbeeld:
Persoon met id 1 koopt iets ter waarde van 12.50 en dat is bestemd voor hemzelf en persoon 3 en persoon 4. Dus dan krijg je de volgende QUERY's:

INSERT INTO Items(PersonID, Price) VALUES ('$personid','$price');

INSERT INTO Items_Persons(ItemID,PersonID) VALUES ('$itemid','$personid');

En dat itemid is dus de overeenkomst zodat je dus ook kan nagaan voor wie iemand anders iets koopt. Dus het is wel degelijk mogelijk wat jij hier opmerkte:

Op dinsdag 22 januari 2002 09:23 schreef dusty het volgende:
Je model klopt gewoonweg niet.

Persoon B koopt het,
persoon A en C staan dus in de schuld, Nu betaald alleen Persoon A, Hoe hou JIJ dat bij?

[a3konijn]

Sorry dat ik dit topic nu al omhoog schop, maar ik vind het jammer dat ik door bovenstaande discussie nog geen gewenst antwoord gekregen heb.

[dusty]

Op woensdag 23 januari 2002 14:35 schreef a3konijn het volgende:
Sorry dat ik dit topic nu al omhoog schop, maar ik vind het jammer dat ik door bovenstaande discussie nog geen gewenst antwoord gekregen heb.

Persoon met id 1 koopt iets ter waarde van 12.50 en dat is bestemd voor hemzelf en persoon 3 en persoon 4. Dus dan krijg je de volgende QUERY's:

Persoon 3 betaald, wat doe je dan in de database?

[The Noid]

Op woensdag 23 januari 2002 14:41 schreef dusty het volgende:

Persoon 3 betaald, wat doe je dan in de database?

Niets, want het verwerken van betalingen staat niet in de omschrijving

[Verwijderd]

heeremetiid wat een ijzerenheinig geleuter.

Item - PersoonDieBetaalt: n:m relatie
Item - PersoonWaarHetVoorIs: n:m relatie

4 tabels: * is key
Table 1: Persons.
- PersonID *
- Name
- DickLength
- Whatever

Table 2:Items.
- ItemID *
- Description
- PriceInEuro

Table 3: ItemPayingPersons
- ItemID *
- PersonID *
- PersonPayedInEuro (geeft aan hoeveel dit persoon meebetaalde)

Table 4: ItemReceivingPersons
- ItemID *
- PersonID *
- Amount (normaliter 1, maar stel Person neemt zn vriendin mee, dan moet PersonID betalen voor die vriendin, maar die zit niet in de database, dus vul je daar 2 in)

Bouwen, queries er op en draaien. Goeie got, zeg, zoek es op: normalisatie, datamodel

[dusty]

Op woensdag 23 januari 2002 15:08 schreef Otis het volgende:
[..]
Bouwen, queries er op en draaien. Goeie got, zeg, zoek es op: normalisatie, datamodel

Op dinsdag 22 januari 2002 11:01 schreef a3konijn het volgende:
[..](mijn) Model klopt wel.[..]

[Verwijderd]

Overigens moet je niet met B heeft schuld bij A werken, maar met: B heeft t.o.v. de flatkas een saldo van... en A heeft t.o.v. de flatkas een saldo van...

Want, A koopt ook weer wat voor C, C koopt weer wat voor B en zo heb je de circel weer rond. Je creeert een inmens complex geheel door alle saldi van ieder persoon tegenover een ieder ander persoon uit te zetten, terwijl het op het eind geen moer uitmaakt.

Je krijgt dan een lijstje van saldi per persoon wat ze moeten voldoen aan de flatkas admin of wat ze krijgen van de flatkas admin. Dat opgeteld moet 0 zijn.

Trust me, ik heb dit 3 jaar gedaan op een campusflat en het werkte uitstekend, mn proggie werkte ook op die manier en je kunt bewijzen dat het klopt. (voor de paranoia onder je flatgenoten die je niet vertrouwen).

[dusty]

Op woensdag 23 januari 2002 15:21 schreef Otis het volgende:
(voor de paranoia onder je flatgenoten die je niet vertrouwen).

= alle personen die NIET het programma hebben geschreven

[a3konijn]

Op woensdag 23 januari 2002 14:41 schreef dusty het volgende:

[..]


[..]

Persoon 3 betaald, wat doe je dan in de database?

Op dinsdag 22 januari 2002 18:17 schreef a3konijn het volgende:
...
En zodoende gaf ik als voorbeeld:
Persoon met id 1 koopt iets ter waarde van 12.50 en dat is bestemd voor hemzelf en persoon 3 en persoon 4. Dus dan krijg je de volgende QUERY's:

INSERT INTO Items(PersonID, Price) VALUES (1,12.50);

INSERT INTO Items_Persons(ItemID,PersonID) VALUES (112,1);
INSERT INTO Items_Persons(ItemID,PersonID) VALUES (112,3);
INSERT INTO Items_Persons(ItemID,PersonID) VALUES (112,4);

Aangenomen dat 112 het id is van de insert in Items.
...
[..]

Of te wel: Diegene die een item koopt voert het in en heeft het dus ook betaald!!!

[Verwijderd]

Op woensdag 23 januari 2002 15:33 schreef a3konijn het volgende:
[..]
Of te wel: Diegene die een item koopt voert het in en heeft het dus ook betaald!!!

Jij bent zeker 1e jaars, of niet? Ooit met zn 2-en iets betaald voor 'de flat'? Komt vaker voor dan je denkt. Dat soort info kun jij niet in je model stoppen.

Heb ik het nog niet eens over het logische model waar je deze tabels uit hebt gedistilleerd.

Leren ze bij jou op de HIO niet goed modelleren oid? of normaliseren?

[a3konijn]

Op woensdag 23 januari 2002 15:20 schreef dusty het volgende:

[..]


[..]

Niets

Ik heb alleen gesteld dat ieder item toch een uniek prijs zal hebben, dus waarom zou ik niet gelijk het item samen met de prijs en de persoon die het aanschaft(en dus ook betaald) in een tabel stoppen. En ja hieraan voeg ik dan ook een beschrijving toe.
Bovendien komt het nauwelijks voor dat meerdere personen 1 item kopen. En is dat wel het geval dan vult ieder maar zijn eigen aandeel in.
Anders krijg ik 2 tabellen die waarschijnlijk toch evenlang worden.

Table 4: ItemReceivingPersons
- ItemID *
- PersonID *
- Amount (normaliter 1, maar stel Person neemt zn vriendin mee, dan moet PersonID betalen voor die vriendin, maar die zit niet in de database, dus vul je daar 2 in)

Bouwen, queries er op en draaien. Goeie got, zeg, zoek es op: normalisatie, datamodel

Oh ja, dat opslaan van voor hoeveel mensen het geldig is had ik niet vermeld i.v.m. de eenvoud, maar dat komt er uiteraart ook in

[a3konijn]

Op woensdag 23 januari 2002 15:40 schreef Otis het volgende:

[..]

Jij bent zeker 1e jaars, of niet? Ooit met zn 2-en iets betaald voor 'de flat'? Komt vaker voor dan je denkt. Dat soort info kun jij niet in je model stoppen.

Heb ik het nog niet eens over het logische model waar je deze tabels uit hebt gedistilleerd.

Leren ze bij jou op de HIO niet goed modelleren oid? of normaliseren?

Nee hoor, ik ben 6e jaars. 4 jaar WTB en 1 1/2jaar HIO.

En zoals ik al meerdere keren heb gezegd: Tot nu toe voerde iedereen z;n eigen bonnetjes in, dus als je met z'n 2-en iets betaald dan vult iedereen z'n eigen aandeel in. Wij zijn bovendien niet zo gezellig dat we samen boodschappen doen, en als het al voorkomt dan rekenen we nog apart onze dingen af dus hebben we ook 2 bonnetjes.

Maar ik moet je gelijk geven dat het voor de volledigheid en flexibiliteit niet verkeerd zou zijn om het zo op te slaan, alleen dit stond nergens beschreven in wat ik vermee wilde opslaan. En ja ik heb leren modelleren, normaliseren etc. bij vakken als Informatie Analyse alleen dat is alweer een beetje weggezakt.

[dusty]

Op woensdag 23 januari 2002 15:33 schreef a3konijn het volgende:
[..]
Of te wel: Diegene die een item koopt voert het in en heeft het dus ook betaald!!!

Maar persoon 1 had het gekocht dus die heeft het ingevoerd,

Nu wilt persoon 3 zijn gedeelte betalen, lijkt me niet dat hij het item overnieuw in de database moet zetten.

[dusty]

Op dinsdag 22 januari 2002 18:17 schreef a3konijn het volgende:
[..]heb ik de kwestie waar wij nu over twisten ook voorgelegd aan een IT-er op mijn werk die menig cursus over database modellen etc. heeft gevolgd dus hiervan wel degelijk op de hoogte is.[..]

Zouden wij mogen weten WELKE cursussen en WAAR ?

Voornamelijk zodat men hier niet dezelfde fout maakt om dezelfde cursussen te volgen...

[a3konijn]

Op woensdag 23 januari 2002 15:51 schreef dusty het volgende:

[..]

Maar persoon 1 had het gekocht dus die heeft het ingevoerd,

Nu wilt persoon 3 zijn gedeelte betalen, lijkt me niet dat hij het item overnieuw in de database moet zetten.

Nee, want het gaat dan om een nieuw item waaraan een ander bedrag is gekoppeld. Is dit nou echt zo moeilijk om te begrijpen???????????
En als hij item x invoert dan voert hij daarbij natuurlijk ook in voor wie het bestemd was. Het is nl. de verantwoording van de persoon die iets koopt om het ook in te voeren.

En misschien snap ik nu eindelijk waar jullie het over hebben: Stel persoon A koopt iets. Legt dit in de vriezer en een week later denkt persoon B, he dat is lekker dat eet ik op. Hoe voert die persoon dat dan nog in?? Nou dan geef ik je gelijk dan wordt het complex. Maar tot nu toe voert die persoon die dat pakt (B dus) gewoon zelf in en zet daarbij dat A het aangeschaft heeft. In onze vriezer staat nl. de prijs op iets tezamen met diegene die het gekocht heeft. Makkelijk he??

[a3konijn]

Op woensdag 23 januari 2002 16:06 schreef dusty het volgende:

[..]

Zouden wij mogen weten WELKE cursussen en WAAR ?

Voornamelijk zodat men hier niet dezelfde fout maakt om dezelfde cursussen te volgen...

Mmmhhh schiet niet echt op als 2 koppige personen communiceren waarbij ieder z'n gelijk probeert te behalen.

Dusty --> Lees nou nog eens een keer wat mijn bedoeling is om op te slaan. Dan zie je hopelijk toch ook in dat, ondanks dat ik een aantal zaken later niet meer toe kan voegen wegens ontbrekende flexibiliteit ik er toch in op kan slaan wat ik wil!!!!!!!!!!!

[Bananeman]

Op woensdag 23 januari 2002 16:06 schreef dusty het volgende:

[..]

Zouden wij mogen weten WELKE cursussen en WAAR ?

Voornamelijk zodat men hier niet dezelfde fout maakt om dezelfde cursussen te volgen...

Datamodelleren met Tinky Winky en Laa-Laa: een vrolijk avontuur!

3,95 bij de Etos.

Sorry

[a3konijn]

[dusty]

Op dinsdag 22 januari 2002 11:20 schreef dusty het volgende:
Dan blijf je lekker dit model gebruiken. Blijf je lekker hetzelfde tegen je data aankijken dat je bent gewend, vooral niet verder kijken of er betere mogelijkheden zijn.

[a3konijn]

Op woensdag 23 januari 2002 16:21 schreef dusty het volgende:

[..]

Ik heb toch toegegeven dat er betere (lees toekomstig makkelijker uitbreidbare) mogelijkheden zijn!! Maar mijn vraag bovenin is ook niet of dit datamodel niet verder uitgebreid kan worden maar of en zo ja hoe ik met een Query eruit kan halen wat iemand aan schuld staat

[Verwijderd]

Op woensdag 23 januari 2002 16:13 schreef a3konijn het volgende:
[..]
Mmmhhh schiet niet echt op als 2 koppige personen communiceren waarbij ieder z'n gelijk probeert te behalen.

Ok jij je zin: JIJ hebt ongelijk.

Dusty --> Lees nou nog eens een keer wat mijn bedoeling is om op te slaan. Dan zie je hopelijk toch ook in dat, ondanks dat ik een aantal zaken later niet meer toe kan voegen wegens ontbrekende flexibiliteit ik er toch in op kan slaan wat ik wil!!!!!!!!!!!

Wat je wilt kan maar tot op zekere hoogte. Dat wil jij wegrationaliseren onder de noemer "dat komt toch nooit voor" (De lijfspreuk van de gemiddelde beun de haas, je wel bekend als konijn zijnde) maar dat is natuurlijk geen basis voor een vraag hier. Als je wilt dat mensen hier jou antwoord geven waar je wat aan HEBT, luister dan eens en wees niet zo stronteigenwijs.

Jouw model is niet gebaseerd op ENIGE logica (mja, wellicht dezelfde als waar je sig op is gebaseerd wellicht) en dat lul je niet recht door bovengenoemde rationalisatiestappen toe te passen. Je model _KLOPT NIET_. Period. Dat volhouden is fijn voor de kronieken maar werkt niet echt in je voordeel.

Pas de kennis die je hebt opgedaan op je HIO eens toe in de praktijk. Doe anders die trimesters eens over, want de effectiviteit van die kennis 'in het veld' is 0.0

Ja dit is een rant. Af en toe krijg ik teveel kippevel van het amateurisme in dit forum.

[a3konijn]

Otis --> Heb ik dan gezegd dat ik vind dat jou datamodel niet voldoet?? Ik heb hier zeker nog wat van opgestoken, bedankt daarvoor. Alleen bij Dusty gaat het erom dat hij iedere keer komt met een vraag als:

Op dinsdag 22 januari 2002 09:23 schreef dusty het volgende:
Je model klopt gewoonweg niet.

Persoon B koopt het,
persoon A en C staan dus in de schuld, Nu betaald alleen Persoon A, Hoe hou JIJ dat bij?

of

Op woensdag 23 januari 2002 14:41 schreef dusty het volgende:

[..]


[..]

Persoon 3 betaald, wat doe je dan in de database?

of

Op woensdag 23 januari 2002 15:51 schreef dusty het volgende:

[..]

Maar persoon 1 had het gekocht dus die heeft het ingevoerd,

Nu wilt persoon 3 zijn gedeelte betalen, lijkt me niet dat hij het item overnieuw in de database moet zetten.

Terwijl dit niet in m'n omschrijving staat of hij gewoon slecht leest want het kan er wel in opgeslagen worden.

En ja, natuurlijk is dit model niet volledig en kan het beter alleen dat hoeft nu niet, omdat ik het enigszins eenvoudig wil houden om e.e.a. zo snel mogelijk te kunnen implementeren. Bovendien was het in het vorige programma wat wij hiervoor gebruikten ook niet mogelijk om meerdere kopers bij een item in te voeren en nog wel meer van die zaken en toch voldeed dat programma gewoon goed (al 4 jaar!!!)

Pas de kennis die je hebt opgedaan op je HIO eens toe in de praktijk. Doe anders die trimesters eens over, want de effectiviteit van die kennis 'in het veld' is 0.0

Ik heb ook geleerd dat als iemand een beschrijving geeeft van wat hij op wilt slaan je daarbij niet nog van alles moet verzinnen wat eventueel toekomstig mogelijk moet zijn.

Dus op basis van deze beschrijving:

In een studentenhuis waar 4 personen wonen wordt er in wisselbeurt gekookt en er worden ook andere artikelen aangeschaft die voor algemeen gebruik zijn. Zodoende moet er dus opgeslagen worden wie van de 4 personen iets aangeschaft heeft (dit kan een pak wc-rollen zijn, maar dus ook een complete maaltijd, vandaar dat een item bijna altijd een unieke prijs zal hebben) wat de prijs daarvan was en voor wie dat allemaal bestemd was. Het kan hierbij voorkomen dat een persoon iets koopt voor iemand anders dus dat hij het zeg maar voorschiet.

concludeer jij dat er meerdere mensen iets tezamen aanschaffen????

[Goodielover]

OK, bemoei ik me er ook nog maar even mee.
Is het de bedoeling dat je uit de opgeslagen gegevens kan herleiden dat de verdeling van aankopen juist heeft plaatsgevonden, of kan je de verwerking ook direct doorvoeren in de DB en bijvoorbeeld het totale bedrag nergens opslaan.

Ik stel me zoiets voor:

code:

Aankoper   Artikel_omschrijving  Bedrag Wie_doet_er_mee
Jopie   Aardappelen      2,00   Erik, Jan en Piet
Piet     Uien           1,00   Jan Erik
Jan   Warme maaltijd 11/2   7,00   Piet

Uit deze info is alles te halen en dit is precies het voorgestelde datamodel.
So far so good.

Nu alleen: wat wil je me het model.
Wil je registreren en de berekining complex laten zijn,
of
niet aankopen registeren en berekening simpel
of
Beide en redundantie in het datamodel

Zeg het maar