DB model klantensysteem
Hey,
Ik vind het nu stilaan tijd om mijn eigen klantensysteem te maken. Ik zit momenteel nog in de beginfase. Ik ben aan het uitdenken hoe ik alles ga laten werken. Ik was nu bezig aan mijn db model en dacht om dit zo te doen.
Een tabel gebruikers met gebruikersnaam, wachtwoord, etc..
Een tabel opdrachten: afgewerkte opdrachten met info erover. Elke gebruiker ziet dan een lijst met opdrachten die ik voor hen gedaan heb.
Een tabel lopende opdrachten: klanten zien dan aan welke opdrachten ik bezig ben voor hen.
In de admin zou ik dan bijvoorbeeld lopende opdrachten verplaatsen naar afgewerkte opdrachten enzo.
Ik denk wel dat dit een goeie aanpak is, maar ik had ook graag eens geweten hoe jullie dit zouden maken.
Ik vind het nu stilaan tijd om mijn eigen klantensysteem te maken. Ik zit momenteel nog in de beginfase. Ik ben aan het uitdenken hoe ik alles ga laten werken. Ik was nu bezig aan mijn db model en dacht om dit zo te doen.
Een tabel gebruikers met gebruikersnaam, wachtwoord, etc..
Een tabel opdrachten: afgewerkte opdrachten met info erover. Elke gebruiker ziet dan een lijst met opdrachten die ik voor hen gedaan heb.
Een tabel lopende opdrachten: klanten zien dan aan welke opdrachten ik bezig ben voor hen.
In de admin zou ik dan bijvoorbeeld lopende opdrachten verplaatsen naar afgewerkte opdrachten enzo.
Ik denk wel dat dit een goeie aanpak is, maar ik had ook graag eens geweten hoe jullie dit zouden maken.
Gewijzigd op 01/01/1970 01:00:00 door Cedric
Waarom zou je de tabel opdrachten en lopende opdrachten los van elkaar maken? Ik zou er 1 tabel van maken, waarin je alle opdrachten zet. Zet er een kolom afgerond (type:date) in en zet daar de datum in wanneer die is afgerond (kan je in je "admin-panel" die je zelf zou maken bijvoorbeeld met een checkbox aanvinken, en is die aangevinkt, dan komt in die kolom de huidige datum te staan)
Zo kan je ook nog namelijk de opdrachten op volgorde van afronding laten zien, en hou je de boel keurig in 1 tabel.
In de afgeronde en lopende projecten heb je (bij jou opzet) namelijk dezelfde informatie staan, alleen zijn de projecten in de 1e tabel afgerond en in de andere niet. -> verplaatsen kost meer rekencapaciteit, als zal je dat niet merken, omdat jezelf alleen kan verplaatsen) maar 2 tabellen is gewoon overbodig.
Zo kan je ook nog namelijk de opdrachten op volgorde van afronding laten zien, en hou je de boel keurig in 1 tabel.
In de afgeronde en lopende projecten heb je (bij jou opzet) namelijk dezelfde informatie staan, alleen zijn de projecten in de 1e tabel afgerond en in de andere niet. -> verplaatsen kost meer rekencapaciteit, als zal je dat niet merken, omdat jezelf alleen kan verplaatsen) maar 2 tabellen is gewoon overbodig.
Nu ik er over nadenk heb je wel gelijk. Ik had er eigenlijk nooit over gedacht om alles in 1 tabel te zetten. Dan heb ik gewoon AND afgewerkt = 1 toe te voegen aan mijn query :)
Gewijzigd op 01/01/1970 01:00:00 door Cedric
Misschien ook wel handig voor klanten om überhaupt te zien welke projecten je hebt lopen, of bijvoorbeeld een "verwachte afrondingsdatum" erin te zetten, is deze voorbij, en niet aangepast, dan kan dit bijv automatisch (op mijn manier met de datum in afgerond) als afgerond worden bestempeld -> Al naar gelang jou eigen invulling.
Voor de rest heb je inderdaad een tabel gebruikers nodig, en de tabel opdrachten, dat zit denk ik wel goed, let wel op dat je de wachtwoorden in de tabel gebruikers/ klanten goed beveiligd!
Voor de rest heb je inderdaad een tabel gebruikers nodig, en de tabel opdrachten, dat zit denk ik wel goed, let wel op dat je de wachtwoorden in de tabel gebruikers/ klanten goed beveiligd!
Dit is slechts een idee, redelijk abstract maar houd ik van!
structuur:
customers
- customerid
- firstname
- infix
- lastname
- etc
primary_key op customerid en uniqe op KVK/BTW ?
project_status_types
statusid
name
projects
projectid
customerid
name
description
deadline
deadline = datetime
project_to_status_types
projectid
statusid
insertdate
primary_key(projectid,statusid)
en insertdate = datetime
En zo kunnen we nog verder gaan met facturen, orders e.d. maar dit is om je een abstract idee te geven :)
structuur:
customers
- customerid
- firstname
- infix
- lastname
- etc
primary_key op customerid en uniqe op KVK/BTW ?
project_status_types
statusid
name
projects
projectid
customerid
name
description
deadline
deadline = datetime
project_to_status_types
projectid
statusid
insertdate
primary_key(projectid,statusid)
en insertdate = datetime
En zo kunnen we nog verder gaan met facturen, orders e.d. maar dit is om je een abstract idee te geven :)
Inderdaad weer een goed idee om klanten te laten zien aan welke opdrachten ik momenteel bezig ben. Ik heb nu al het een en ander aangepast ik heb nu dit:
Een verwachte afrondingsdatum heb ik niet nodig, dan kan ook via msn ofzo :P Wachtwoorden gaan in md5 naar de database gaan. Ik doe vooral scripting en basing. Ik kan dus nog gewoon een veld aanmaken en daar een downloadlink instoppen waarschijnlijk?
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE `opdrachten` (
`id` int(11) NOT NULL auto_increment,
`uid` int(11) NOT NULL default '',
`type` varchar(100) NOT NULL default '',
`prijs` varchar(100) NOT NULL default '',
`betaald` varchar(100) NOT NULL default '0',
`software` varchar(100) NOT NULL default '',
`opmerkingen` text NOT NULL,
`afgewerkt` int(1) NOT NULL default '0',
`datum` date NOT NULL default '0000-00-00',
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
`id` int(11) NOT NULL auto_increment,
`uid` int(11) NOT NULL default '',
`type` varchar(100) NOT NULL default '',
`prijs` varchar(100) NOT NULL default '',
`betaald` varchar(100) NOT NULL default '0',
`software` varchar(100) NOT NULL default '',
`opmerkingen` text NOT NULL,
`afgewerkt` int(1) NOT NULL default '0',
`datum` date NOT NULL default '0000-00-00',
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
Een verwachte afrondingsdatum heb ik niet nodig, dan kan ook via msn ofzo :P Wachtwoorden gaan in md5 naar de database gaan. Ik doe vooral scripting en basing. Ik kan dus nog gewoon een veld aanmaken en daar een downloadlink instoppen waarschijnlijk?
@Cedric
Kijk ook even naar de opzet van kees, software zou ik via een koppeltabel doen:
tabel Software
id
naam
tabel opdr_soft
id
soft_id
opdr_id
De prijs hoort niet in een varchar veld, en ik ben wel benieuwd wat er in de kolom betaald moet komen te staan?
Voor wat betreft het type geld hetzelfde als de software, waarschijnlijk heb je een aantal vaste typen opdrachten, -> Doe dit wederom via een koppeltabel
Kijk ook even naar de opzet van kees, software zou ik via een koppeltabel doen:
tabel Software
id
naam
tabel opdr_soft
id
soft_id
opdr_id
De prijs hoort niet in een varchar veld, en ik ben wel benieuwd wat er in de kolom betaald moet komen te staan?
Voor wat betreft het type geld hetzelfde als de software, waarschijnlijk heb je een aantal vaste typen opdrachten, -> Doe dit wederom via een koppeltabel
'kees:
Nooit en te nimmer een KvK of BTW-nummer als PK op een klant gooien. Tenzij je natuurlijk geen overheidsinstellingen wilt hebben als klant...primary_key op customerid en uniqe op KVK/BTW ?
Elwin
'type' klinkt mij in de oren als een hele serie types die voor de diverse opdrachten echter wel hetzelfde zijn. Dit hoort dan in een aparte tabel te staan die je met een FK wordt gekoppeld aan de opdrachten.
'afgewerkt' is een status en er bestaan meerdere statussen. Wederom een aparte tabel.
'prijs' is een getal, een VARCHAR slaat dus nergens op. Of word jij betaald met bv. 40 kamelen? Een DECIMAL ligt voor de hand.
'betaald' lijkt mij gekoppeld aan de financiele administratie en hoort niet in deze tabel te staan.
'opmerkingen', 1 opdracht kan meerdere opmerkingen hebben. Sla dit dus op in een aparte tabel.
Vraagje: Hoe ga jij de voortgang van een project bepalen en opslaan?
'afgewerkt' is een status en er bestaan meerdere statussen. Wederom een aparte tabel.
'prijs' is een getal, een VARCHAR slaat dus nergens op. Of word jij betaald met bv. 40 kamelen? Een DECIMAL ligt voor de hand.
'betaald' lijkt mij gekoppeld aan de financiele administratie en hoort niet in deze tabel te staan.
'opmerkingen', 1 opdracht kan meerdere opmerkingen hebben. Sla dit dus op in een aparte tabel.
Vraagje: Hoe ga jij de voortgang van een project bepalen en opslaan?
'Elwin:
Elwin
'kees:
Nooit en te nimmer een KvK of BTW-nummer als PK op een klant gooien. Tenzij je natuurlijk geen overheidsinstellingen wilt hebben als klant...primary_key op customerid en uniqe op KVK/BTW ?
Elwin
Geen primary key, een UNIQE index, deze laat ook null waarde toe, maar een KVK of BTW nummer mag nooit hetzelfde zijn of ze moeten allebei null zijn ;)
'pgFrank:
'afgewerkt' is een status en er bestaan meerdere statussen. Wederom een aparte tabel.
Als afgewerkt -> Ja of Nee (0 of 1) is, dan hoeft het niet in een aparte tabel, maar het zou denk ik inderdaad samengevoegd moeten worden met de status. En dan moet je wel een koppeltabel gebruiken.
Plots al die commentaar :P Ik ga proberen het een en ander te verduidelijken:
Software: komt de gebruikte software te staan bv: photoshop, dreamweaver
Prijs is varchar omdat ik er € teken zou inzetten?
Type = bv slicing, scripting. Waarom zou dit in een andere tabel moeten?
Afgewerkt = 1 of 0
Betaald = 1 of 0 (of het op mijn rekening staat)
Opmerkingen = een tekstje
De vooruitgang bepalen is makkelijk, gewoon afgewerkt van 0 naar 1 veranderen.
Ik snap niet dat jullie voor zoveel dingen een andere tabel willen. Zo moet het toch ook lukken?
Software: komt de gebruikte software te staan bv: photoshop, dreamweaver
Prijs is varchar omdat ik er € teken zou inzetten?
Type = bv slicing, scripting. Waarom zou dit in een andere tabel moeten?
Afgewerkt = 1 of 0
Betaald = 1 of 0 (of het op mijn rekening staat)
Opmerkingen = een tekstje
De vooruitgang bepalen is makkelijk, gewoon afgewerkt van 0 naar 1 veranderen.
Ik snap niet dat jullie voor zoveel dingen een andere tabel willen. Zo moet het toch ook lukken?
Gewijzigd op 01/01/1970 01:00:00 door Cedric
@Robert: afgewerkt is geen boolean, geen true of false.
Stel je voor dat je een tabel hebt waarin je namen van gebruikers gaat opslaan:
id | robert | pgFrank | kees
--------------------------------
1 | TRUE | FALSE | FALSE
2 | FALSE| TRUE | FALSE
3 | FALSE| FALSE | TRUE
Lijkt mij niet helemaal de juiste manier om de namen op te slaan... Dat geldt ook voor de status, 'afgewerkt' is een status en omdat je deze een 1-op-meer relatie heeft, komt deze in een aparte tabel te staan.
Geen koppeltabel, tenzij een opdracht meerdere gelijktijdige statussen kan hebben of je per status ook wilt opslaan wanneer deze status van toepassing was.
Stel je voor dat je een tabel hebt waarin je namen van gebruikers gaat opslaan:
id | robert | pgFrank | kees
--------------------------------
1 | TRUE | FALSE | FALSE
2 | FALSE| TRUE | FALSE
3 | FALSE| FALSE | TRUE
Lijkt mij niet helemaal de juiste manier om de namen op te slaan... Dat geldt ook voor de status, 'afgewerkt' is een status en omdat je deze een 1-op-meer relatie heeft, komt deze in een aparte tabel te staan.
Geen koppeltabel, tenzij een opdracht meerdere gelijktijdige statussen kan hebben of je per status ook wilt opslaan wanneer deze status van toepassing was.
Ik begrijp het niet echt, wat bereiken jullie meer door al die verschillende tabellen aan te maken? Met deze tabellen kan ik toch evenveel doen als jullie met meerdere tabellen?
Gewijzigd op 01/01/1970 01:00:00 door Cedric
'Cedric:
Aparte tabel! Ik neem tenminste aan dat meerdere opdrachten van dezelfde software gebruik maken. En omdat 1 opdracht meerdere software-pakketten kan gebruiken, heb je daarvoor ook nog een koppeltabel nodig.Software: komt de gebruikte software te staan bv: photoshop, dreamweaver
Quote:
Hoe verzin je het! Hoe denk je nu bv. de btw te gaan berekenen of de waarde van de opdrachten op te tellen? € is een weergave, die kan dus nooit en te nimmer in de database terecht komen. Wil jij de valutacode opslaan, maak dan een kolom 'valutacode' aan en zet daar de waarde EUR in.Prijs is varchar omdat ik er € teken zou inzetten?
Quote:
Omdat je mij niet wijs maakt dat dit slechts 1x voorkomt. Dit komt bij vrijwel iedere opdracht voor, het gegeven 'scripting' sla je dus 1x op en verder verwijs je alleen maar naar deze waarde.Type = bv slicing, scripting. Waarom zou dit in een andere tabel moeten?
Quote:
Heb je wel eens van normaliseren gehoord?Ik snap niet dat jullie voor zoveel dingen een andere tabel willen. Zo moet het toch ook lukken?
Ik heb al van normaliseren gehoord, maar ik zou bijgod niet weten wat het is. :P Ik ga akkoord dat het type bv slicing in meerdere opdrachten van toepassing kan zijn. Maar waarom zou ik dat niet gewoon kunnen echoën op een pagina in een tabel bij Type?
Gewijzigd op 01/01/1970 01:00:00 door Cedric
Quote:
Wat heeft echo nu met het datamodel te maken? Dat verband zie ik even niet.Maar waarom zou ik dat niet gewoon kunnen echoën op een pagina in een tabel bij Type?
Edit: Dit heb je heel hard nodig - link
Gewijzigd op 01/01/1970 01:00:00 door Frank -
Welja, het staat zo in de database, zoals het er nu in zou staan werkt het toch gewoon? Ik kan het nu ook netjes weergeven enzo...
Edit:
Van dat normaliseren snap ik niet te veel, kan mij iemand eens uitleggen waarom dit nodig/verplicht is? Ik heb namelijk nog nooit problemen gehad met de manier waarop ik het nu doe...
Van dat normaliseren snap ik niet te veel, kan mij iemand eens uitleggen waarom dit nodig/verplicht is? Ik heb namelijk nog nooit problemen gehad met de manier waarop ik het nu doe...
Gewijzigd op 01/01/1970 01:00:00 door Cedric
Scheelt ruimte in je tabel, -> Alleen de koppeling tussen de tabellen is 2 keer een getal, die neemt minder ruimte in dan de hele text "slicing".
Bovendien zal je ook opdrachten hebben die uit slicing, en coding kunnen bestaan -> Hoe had jij dit anders in gedachten?
Voor wat betreft de afgerond en betaald, ga ik niet met je mee Frank, een 0 of een 1 heb je anders ook, waarom zou je daar dan een aparte tabel voor maken?
Bovendien zal je ook opdrachten hebben die uit slicing, en coding kunnen bestaan -> Hoe had jij dit anders in gedachten?
Voor wat betreft de afgerond en betaald, ga ik niet met je mee Frank, een 0 of een 1 heb je anders ook, waarom zou je daar dan een aparte tabel voor maken?
'Robert_Deiman:
Bovendien zal je ook opdrachten hebben die uit slicing, en coding kunnen bestaan -> Hoe had jij dit anders in gedachten?
Dat wordt via de admin in een inputveld getypt...
@pgFrank
SELECT SUM(CAST(str_replace(price,'€','') DECIMAL(10,2))) AS `total`
Haha, grapje he ;) om cedric niet op slechte ideeën te brengen overigens!
SELECT SUM(CAST(str_replace(price,'€','') DECIMAL(10,2))) AS `total`
Haha, grapje he ;) om cedric niet op slechte ideeën te brengen overigens!




