ik wil graag een kleine webshop maken, voor game currency verkoop. nu kan ik hier genoeg kant en klare pakketten voornemen, maar leer ik daar niks van.
dit is de database die ik tot nu toe heb opgezet.
Zoals opvalt, heb ik geen aparte klant tabel hier, twijfel of ik voornaam en achternaam nog in 1 aparte klanten tabel gooi, maar gebruikers volstaat.
nu vroeg ik me af hebben jullie aan de hand van deze database nog tips? belangrijke dingen die ik over het hoofd zie?
ook zit ik met het volgende. aangezien het voornamelijk op game currency/credits gaat. hoe ik dit bij hou met in en verkoop? ik wil in de toekomst als de webshop zelf af is namelijk alles digitaal bijhouden, winst per dag,maand/jaar btw ect.
nu kan ik prima de inkoop bijhouden in de tabel inkoop. en de verkoop uit de orders halen, maar nooit bijvoorbeeld de precieze winst per bijvoorbeeld order of dag bijhouden. aangezien ik op 1dag bijvoorbeeld 100 credits voor verschillende prijzen inkoop. en in de komende dagen voor verschillende prijzen verkoop.
is hier in goede oplossing voor om dit toch bij te kunnen houden?
en wat is normaal qua btw? btw ex of inc bijhouden in de database?
Waar ik nu al direct tegenaan loop is dat je nogal inconsistent bent met de maximale lengte van je varchars tussen de verschillende tabellen. Ook zijn ze in sommige gevallen nogal kort. Daarbij kijk ik ook meteen naar velden als role_code. Waarom moet dit een varchar zijn? Is het niet veel logischer om dit gewoon een auto increment te maken? Stip ik ook nog even INT(11) aan, maak hier gewoon 1 van, het maakt op schijf niks uit, maar tijdens het doorsturen tussen je database en PHP wordt iedere int dan aangevuld tot 11 tekens, wat nogal een impact kan hebben op je performance, afhankelijk van hoe groot je resultsets zijn.
Inkoop en verkoop doe je uiteraard volgens de fifo methode: wanneer je 5 credits inkoopt voor bedrag x gevolgd door 20 credits voor bedrag y kun je de eerste 5 verkochte credits verrekenen met bedrag x, de rest met bedrag y. Ik heb niet goed gekeken, maar ik hoop dat je inkooporders hetzelfde detail qua specificatie bevatten als de verkooporders, anders kun je hier geen nauwkeurige statistieken uit halen.
Gaan we naar de BTW:
Meerdere wegen leiden naar Rome, maar normaliter zul je je productprijzen in beginsel opslaan ex BTW, en hier het vereiste percentage bij optellen voor je verkoopweergave. Je specificeert immers op een verkoopfactuur ook ex BTW met apart de genoemde BTW tarieven en bedragen. BTW kan wel eens wijzigen, dus je moet zorgen dat je dit op een correcte manier normaliseert, bijvoorbeeld met BTW tarieven (laag, hoog etc) en begin/einddatums van de specifieke percentages die hierbij horen.
Voornaam en familienaam ALTIJD afzonderlijk
Zelfde voor adres gegevens Straat, nr, bus, gemeente, (zipcode,) postcode (, land) zijn afzonderlijke velden.
zip is land afhankelijk en land enkel als er meerdere landen zijn.
Waar ik nu al direct tegenaan loop is dat je nogal inconsistent bent met de maximale lengte van je varchars tussen de verschillende tabellen. Ook zijn ze in sommige gevallen nogal kort. Daarbij kijk ik ook meteen naar velden als role_code. Waarom moet dit een varchar zijn? Is het niet veel logischer om dit gewoon een auto increment te maken? Stip ik ook nog even INT(11) aan, maak hier gewoon 1 van, het maakt op schijf niks uit, maar tijdens het doorsturen tussen je database en PHP wordt iedere int dan aangevuld tot 11 tekens, wat nogal een impact kan hebben op je performance, afhankelijk van hoe groot je resultsets zijn.
Hier heb je helemaal gelijk in zal dit even aanpassen.
Ben van Velzen op 21/08/2016 00:21:50
Inkoop en verkoop doe je uiteraard volgens de fifo methode: wanneer je 5 credits inkoopt voor bedrag x gevolgd door 20 credits voor bedrag y kun je de eerste 5 verkochte credits verrekenen met bedrag x, de rest met bedrag y. Ik heb niet goed gekeken, maar ik hoop dat je inkooporders hetzelfde detail qua specificatie bevatten als de verkooporders, anders kun je hier geen nauwkeurige statistieken uit halen.
alleen hoe ik fifo verwerken in de database?
1 of 2 tabellen maken. stock_in en stock_out met daar de inkoop, verkoop prijzen bij?
of 1 tabel stock maar daarin dan stock_in en stock_out en huidige voorraad.
zou je hier misschien een voorbeeld van kunnen geven?
Voorraad is iets anders dan inkoop en verkoop. Voorraad is het resultaat van verkoop tegen inkoop. Wanneer je dus je verkopen koppelt aan ingekochte producten kun je het eenvoudig bijhouden.
gebruikers_role
- combinatie van nederlands en engels
- verkeerde mix van enkelvoud/meervoud die de relatie niet goed weerspiegelt
- hier gebruik je overal een (engelse?) prefix, maar in andere tabellen niet, waarom?
Maak van de tabelnaam gebruiker_rollen en van de prefix rol ofzo?
gebruikers_rechten
- verkeerde mix van enkelvoud/meervoud die de relatie niet goed weerspiegelt
- wees duidelijk(er) in welke kolommen met elkaar in verbinding staan, indien gebruikers_rechten.gebruikers_rollen gekoppeld is aan gebruikers_role.role_naam noem dit dan ook gebruiker_role_naam... (of beter gebruiker_rol_naam dus)
gebruikers
- op grond van de naam role_code zou je vermoeden dat deze gekoppeld is aan gebruikers_role.role_code maar de lengte van de kolommen doet vermoeden dat dit toch gebruikers_role.role_naam moet zijn, wat is het nu?
...
En zo kan ik nog wel even doorgaan.
In welke database wil je dit uiteindelijk gaan maken?
Ik zou beginnen met het opstellen van wat richtlijnen/regels voor naamgeving want op deze manier zal het gebruik (ook al zit de structuur (mogelijk?) verder goed in elkaar) allesbehalve intuïtief zijn.
Maar tis al een stap in de goede richting dat je op deze manier in ieder geval iets documenteert.
Desalniettemin kan dit ontwerp qua naamgeving nog wel wat iteraties gebruiken.
Bedankt allemaal voor de reacties, heb het een en ander veranderd. heb nog niet overal de juiste value/waarde bijgezet omdat ik die nog niet allemaal weet.
Ziet er volgens mij al een stuk beter uit, alleen zit ik nog een beetje met het fifo in me maag. hoe ga ik dit precies aanpakken? heb nu in de tabel inkoop een voorraad kolom meegegeven. is er een mogelijkheid om straks te kijken via 1 query te kijken welke inkoop eerst is gedaan, en daar dan de voorraad af te halen, en zodoende bij eventuele meerdere rijen?
Nogmaals: voorraad is het *resultaat* van verkoop - inkoop. Je kunt dus een aparte voorraad tabel maken met triggers op inkoop en verkoop. Voorraad zet je sowieso niet bij je inkoop in.
Een ander puntje daarbij is: wanneer je iets in je inkoop tabel zet, is de inkoop dan al afgerond of moet je dan nog wachten op je voorraad (orderstatus, eventueel per item dus), idem voor verkoop: is de order altijd al betaald wanneer deze als inkooporder wordt ingevoerd? (niet handig, dan kun je eventuele problemen met verkopen lastig afhandelen met je klanten).
Nogmaals: voorraad is het *resultaat* van verkoop - inkoop. Je kunt dus een aparte voorraad tabel maken met triggers op inkoop en verkoop. Voorraad zet je sowieso niet bij je inkoop in.
Een ander puntje daarbij is: wanneer je iets in je inkoop tabel zet, is de inkoop dan al afgerond of moet je dan nog wachten op je voorraad (orderstatus, eventueel per item dus), idem voor verkoop: is de order altijd al betaald wanneer deze als inkooporder wordt ingevoerd? (niet handig, dan kun je eventuele problemen met verkopen lastig afhandelen met je klanten).
Als er een inkoop is gedaan, is deze gelijk afgerond. voor een verkoop, zitten er bij bestellingen meerdere statussen waarna de verkoop rond is. voorraad bijhouden in een aparte tabel gaat het probleem ook niet worden. waar ik mee mee zit hoe ik nu ooit terug kunnen vinden. wat bijvoorbeeld de winst per order,per dag/maand ect.? aangezien het kan dat ik in bijvoorbeeld 100 stuks verkoop voor 1 euro per stuk. waarvan er 30 ingekocht zijn voor .60 cent en 70 voor 0.65 cent.
hoe ga ik dit netjes in de database opslaan? zodat ik later makkelijk de winst ect kan ophalen. aangezien inkoop/verkoop prijzen van een game curreny wisselend zijn.
De grap is, dat hoef je niet op te slaan, want dit zijn zaken die je kunt berekenen. De query zal niet eenvoudig worden, maar je kunt "gewoon" ophalen wat je inkopen waren en deze afzetten tegen je verkopen. Dat is gewoon een telsommetje. Je zou voor de eenvoud in je order items kunnen opslaan welke inkooporder items daarbij horen, of deze zaken koppelen aan je voorraadmutaties, maar deze denormalisatie is zeker niet noodzakelijk.
De grap is, dat hoef je niet op te slaan, want dit zijn zaken die je kunt berekenen. De query zal niet eenvoudig worden, maar je kunt "gewoon" ophalen wat je inkopen waren en deze afzetten tegen je verkopen. Dat is gewoon een telsommetje. Je zou voor de eenvoud in je order items kunnen opslaan welke inkooporder items daarbij horen, of deze zaken koppelen aan je voorraadmutaties, maar deze denormalisatie is zeker niet noodzakelijk.
Hey ben,
ik snap dat ik gewoon een query kan ophalen, en die kan afzetten tegen me verkopen. alleen omdat het continu met variabel prijzen gaat heb ik geen idee hoe ik dit zou moeten doen.
stel ik heb nu inkoop
sku-datum - prijs - hoeveelheid
rs01-24-08 - 0,65 - 50
rs01-24-08 - 0,70 - 80
rs01-23-08 - 0,68 - 20
rs01-23-08 - 0,66 - 40
in dit geval zal de verkoop van 130 stuks. de volgende winst hebben. inkoop(50x0,65=32,5 en 80x0,70=56) totale inkoop is dus 88,5, dus de winst is 156-88,5= 67,5.(hoe ga ik dit ooit in 1 query gedaan krijgen)
en bij de volgende verkoop moet die, weer de andere uit de inkoop tabel nemen, aangezien die andere al verkocht zijn.
