DB model klantensysteem
betaald is een afgeleide van het ontvangen geld. Dat is wat je gaat registreren, inclusief de betaaldatum. Omdat het geld is ontvangen en gelijk is aan de afgesproken prijs, is er betaald. Dat is dus een berekend geheel.
Wanneer iemand van de 2500 euro slechts 1000 euro betaalt, heb je nog een bedrag van 1500 euro openstaan. Hier zul je dus achteraan moeten of het bedrag crediteren. Wanneer jij een TRUE of FALSE gaat gebruiken voor 'betaald', bestaat het risico dat jouw administratie niet klopt: Er is slechts een deel betaald, maar jij hebt per ongeluk 'betaald' op TRUE gezet. Nu zit er een gat in de administratie en ben je een corrupte database rijker.
Gewijzigd op 01/01/1970 01:00:00 door Frank -
Het lijkt wel of je denkt dat ik niet zou controleren of het volledige bedrag betaald is... Op dit moment doe ik de hele administratie met een txt bestandje :P Ik denk wel dat dit al een grote vooruitgang is. Het is echt niet mijn bedoeling om dit hyperuitgebreid te maken en volledig te vertrouwen op het systeem. Zie het liever als een helpende hand voor mij en mijn klanten..
Gewijzigd op 01/01/1970 01:00:00 door Cedric
Met een subquery kan je dan ook de laatste status krijgen :) (ofwel, huidige)
Gewijzigd op 01/01/1970 01:00:00 door Cedric
Ik geef het op.
Alleszins zeer bedankt om mij te proberen op de juiste weg te helpen. Als het afgeraakt laat ik het misschien nog door jullie testen :P Ik kan mij niet inbeelden dat het veel slechter werkt dan een systeem met meerdere tabellen. Je kan van mij nog niet verwachten dan ik alles goed doe he. Een keer dat dit mijn studies worden zal dat zeker beter gaan :) Ik ben tenslotte nog maar 14 hé
Gewijzigd op 01/01/1970 01:00:00 door Cedric
Frank heeft wel gelijk hoor, zover had ik het nog niet bekeken, maar zeker ook met oog op de toekomst is het goed om de boel in zijn geheel volledig goed op te zetten.
Klanten kunnen met die statussen bijvoorbeeld zien hoe snel iets gaat, voor de betaling is het systeem van Frank betrouwbaarder, en je kan met een (wat ingewikkeldere, maar prima te maken!) query vanuit het in totaal betaalde bedrag van een klant van je bepalen welke dingen al zijn betaald, waarbij je natuurlijk begint bij de eerst gemaakte dingen weg te strepen.
Zo hou je voor jezelf een volledig overzicht en weet je altijd precies wat je nog krijgt/ tegoed hebt. Bovendien loop je dan het risico niet wat Frank je schetste.
Vergeet niet dat een simpele MySQL database te vergelijken is met een textbestand, alleen gemakkelijker bij te houden is! Wanneer je het goed opbouwt heeft een database als MySQL (andere varianten, met foreign keys -> Een sleutel die een link naar een andere tabel aangeeft, hebben dat niet zo, mits goed opgebouwd) wel enige meerwaarde tov een textbestand.
Voor wat betreft afgerond heeft Frank ook gelijk -> Zie het zo, je geeft voor een klant aan dat je bijvoorbeeld aan het slicen bent (daarna moet je nog coderen) de klant ziet dat dan op zijn overzichtspagina, vervolgens ga je coderen > andere status, en vervolgens ben je klaar en is de status afgerond. En aangezien je dus meerdere statussen hebt en meerdere cliënten (of meerdere opdrachten van eenzelfde cliënt) kunnen dezelfde status hebben -> Dus aparte tabel.
Op deze manier werkt het systeem sneller en efficiënter, plus dat het de betrouwbaarheid en precisie van het systeem een stuk beter maakt!! Het is maar net wta je zelf wil, maar je kan het het beste in 1 keer goed doen!
Gewijzigd op 01/01/1970 01:00:00 door Cedric
software
-----------
id
pid
naam
status
--------
id
pid
naam
datetime
Dan voor een opdracht de status opvragen adhv het pid. Als ik het goed heb kan ik dan meerdere statussen per item hebben en dan krijg je een overzicht met tijd erbij (zoals iemand hier al gezegd heeft). Voor de software kan ik dan ook alle programma's ophalen adhv het id van het item.
Kom ik een beetje in de buurt of ben ik op de juiste weg??
Als je data dubbel opslaat (muv id's) is je DB nog niet uitgenormaliseerd.
Klaasjan
Dan de vragen: Wat is 'pid' in de tabel 'software' ? In deze tabel staan alleen de softwarepakketten die jij gebruikt. Er is in deze tabel geen enkel verband met enig ander gegeven/tabel.
Dezelfde vraag voor 'status', wat doet 'pid' in deze tabel? En 'datetime' wat doet deze daarin? In deze tabel komt bv. 1x de waarde 'testen' te staan, en dat is het wel. Andere tabellen zijn echter aan deze tabel gekoppeld, en daarin kun je een datumtijdstempel van een status opgeven. Dat kan onmogelijk in de tabel 'status'. Deze tabel wordt uitsluitend gebruikt om een waarde te selecteren.
Maar, wanneer je gaat normaliseren, is het 'verboden' om in tabellen te denken. Dat gaat helemaal fout! Normaliseren doe je door op papier de diverse soorten data te onderkennen, niet door in tabellen te gaan denken.
Pas wanneer je helemaal klaar bent met normaliseren, ga je kijken hoe de tabellen eruit komen te zien. En zover ben je nog lang niet.
Euh, ik ben al blij dat je zegt dat ik in de goeie richting ga, maar dat is ook het enige wat ik uit je post snap. Wat bedoel je precies?
@pgfrank
pid = pairid, de status moet toch gelinkt worden aan het item?
Gewijzigd op 01/01/1970 01:00:00 door Cedric
Het heeft geen enkele zin om stap 20 uit te voeren wanneer je stap 1 t/m 19 nog niet hebt gedaan, laat staan begrijpt wat daar wordt gedaan. Je loopt hééél ver voor de muziek uit en daar ga je spijt van krijgen.
Stop dus met denken in tabellen, begin met denken in de soorten data die in jouw systeem voorkomen.
klantnaam, userid, status, softwarepakket, dat zijn de soorten data waar we het over hebben. Met normaliseren ga je al dit soort gegevens benoemen en de onderlinge verbanden aanleggen.
Quote:
Klopt, maar dat kan onmogelijk in de tabel 'status' gebeuren. Dat kun je dus ook niet in deze tabel opslaan.@pgfrank
pid = pairid, de status moet toch gelinkt worden aan het item?
pid = pairid, de status moet toch gelinkt worden aan het item?
Gewijzigd op 01/01/1970 01:00:00 door Frank -
type werk
prijs
status
software
opmerkingen
datum wanneer een nieuwe status is toegepast
datum wanneer het project gestart is
userid
gebruikersnaam
wachtwoord
ipadres
sleutel
Denk dat dit is wat ik zoal nodig heb. Nu moet dit in tabellen gezet worden?
Gewijzigd op 01/01/1970 01:00:00 door Cedric
Quote:
Nee, dat ga je normaliseren.Nu moet dit in tabellen gezet worden?
Print die tutorial eens uit en ga stap voor stap de verschillende onderdelen uitwerken. Het is nog lang geen tijd om de tabellen aan te gaan maken! Ga er voor zitten, normaliseren is niet eenvoudig maar wel een onmisbare basis.
Heb niet de illusie dat je dit in een paar uur/dagen doorhebt, daar echt wel meer tijd overheen.
Edit: Ik kan even geen goede vergelijking vinden, maar met een beetje beeldspraak...
Jij wilt je vrienden verrassen met een zelfgemaakte taart en jij hebt nog nooit een taart gebakken. Jij begint nu de gebaksschoteltjes, de vorkjes en een groot mes en vraagt mij hoe je de taart moet snijden. Welke taart?
Je hebt nauwelijks een idee wat voor een taart jij wilt gaan bakken, hebt de ingredienten niet in huis, weet niet hoe de oven werkt, laat staan waar de bakvorm ligt en of hoe de mixer werkt... Pak het recept er bij, zoek alle ingredienten bij elkaar en ga 1 voor 1 de boel verwerken. Wanneer je daarmee klaar bent en de boel keurig hebt gebakken, dan wordt het pas tijd voor het betere snijwerk. Zo ook met jouw database en zijn tabelletjes.
Eerst bakken en daarna pas snijden!
Gewijzigd op 01/01/1970 01:00:00 door Frank -