Database opbouw tips gezocht
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?
ik hoor jullie suggesties en tips graag
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.
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.
Jan
Ben van Velzen op 21/08/2016 00:21:50:
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?
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.
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?
bijvoorbeeld.
inkoop
datum - prijs - hoeveelheid - voorraad
24-08 - 0,65 - 50 - 50
24-08 - 0,70 - 80 - 80
23-08 - 0,68 - 20 - 20
Als er nu bijvoorbeeld 60 stuks gekocht worden, zou het ongeveer zou moeten worden denk?
inkoop
datum - prijs - hoeveelheid - voorraad
24-08 - 0,65 - 50 - 0
24-08 - 0,70 - 80 - 70
23-08 - 0,68 - 20 - 20
Maar is dit mogelijk in een query?,
en iemand nog een simpel voorbeeld hoe ik in dit geval dan de winst kan opmaken van bijvoorbeeld 1 order? aangezien ik met 2 inkoop prijzen zit.
alvast bedankt voor jullie nieuwe tips en adviesen
Thomas van den Heuvel op 21/08/2016 15:03:37:
In welke database wil je dit uiteindelijk gaan maken?
In welke database wil je dit uiteindelijk gaan maken?
mysql
Gewijzigd op 24/08/2016 00:07:57 door Jaap evidor
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).
Ben van Velzen op 24/08/2016 00:33:52:
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).
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.
Ben van Velzen op 24/08/2016 11:34:32:
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
en ik heb de volgende verkopen.
verkopen
sku - datum - prijs - hoeveelheid
rs01- 24-08 - 1,20 - 130
rs01- 24-08 - 1,25 - 50
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.
http://www.google.nl/search?q=inkoop+verkoop+fifo
http://www.administratievoeren.nl/fifo.html
http://www.zzp-bedrijf.nl/boekhouding/cursus-boekhouden-voorraad-fifo-systeem/
http://forum.scholieren.com/showthread.php?t=1796162
Adoptive Solution op 24/08/2016 14:41:28:
snap de bedoeling van fifo, gaat me er alleen meer om dat ik geen idee heb hoe ik dit in de toekomst met 1 query kan uivoeren.
Begin voorraad met prijs.
Beetje erbij
Wat is het resultaat.
Beetje eraf.
Wat is het resultaat.
Lineair.
Klinkt niet briljant, maar dat ben ik ook niet.
Ben van Velzen op 24/08/2016 16:08:25:
Dat is de strekking inderdaad, en helaas kun je dat in MySQL waarschijnlijk niet in 1 query doen. Eventueel met wat gegoochel met temporary tabel wel overigens. Het laatste systeem dat ik hiervoor gebouwd heb ging door tot op factuurniveau, waardoor je gewoon elke dag inkoop- en verkoopfacturen tegen elkaar weg kon strepen. Immers; je totaalbedrag is je uitgave van die dag en de verkoop van die dag: wanneer ik vandaag voor 1000 euro voorraad inkoop (en betaal) en voor 1500 euro verkoop dan is mijn resultaat 500 euro. De inkoop van vandaag heeft dan geen invloed meer op het resultaat van morgen. Maar dat is een kwestie van hoe je je resultaten ziet en dus of je je item pas als ingekocht ziet als deze verkocht wordt of op het moment van inkoop.
Maar op deze manier, hou je de winst per dag alleen bij? ik zou graag ook nog de winst per order willen terughalen. en het kan best zijn dat ik op maandag genoeg inkoop voor de hele week, ook dan zou ik de winst per order/dag ect willen kunnen terughalen. maar zoals eerder aangegeven kan het ook zijn dat ik inderdaad elke dag inkoop/verkoop voor variabel prijzen per dag.
volgens mij word het vrij lastig, om in dat geval winst per order te kunnen berekenen?