28. oktober 2010 - 11:12Der er
17 kommentarer og 1 løsning
Produkt + vareenheder - smarteste metode?
Goddag eksperter,
Jeg har opbygget et lille produktsystem med følgende tabeller, hvor der er relationer imellem dem:
tbl_productcategory: ProductCategoryID | Name | Description | Year
tbl_productgroup: ProductGroupID | Name | Description | ProductCategoryID
tbl_product: ProductID | Name | Price | AmountInStock | Units | Description | ProductGroupID
Det fungerer således at man i en produktkategori kan oprette de produktgrupper man ønsker og inde i produktgrupperne kan man ligeledes oprette det antal produkter som man ønsker. Under hvert enkelt produkt kan man så vælge hvor mange man har til rådighed på lager (AmountInStock). Hvis man køber ét eller flere produkter trækkes antallet så fra "AmountInStock", og hvis man sletter transaktionen smides antallet naturligvis tilbage igen. Det fungerer upåklageligt, men her kommer problemet så.
Jeg kunne godt tænke mig at man kunne opdele antal lidt mere specifikt. Hvis man har med annoncer i et magasin at gøre vil man eksempelvis kunne vælge: 1/1 side, ½ side og ¼ side. Hvis man så sælger én ¼ side skal der jo automatisk også trækkes én fra 1/1 side + én ½ side i og med der ryger ¼ side fra magasinet. Men hvis man så "sletter" den bestilling skal der jo automatisk ligges ¼ side tilbage, og dette kan jeg ikke helt gennemskue hvordan jeg gør på den smarteste måde?
Jeg har en idé om at man skal tildele hvert produkt en størrelse/andel (Units) - I ovenstående tilfælde ville det så være: 1/1 side: 100% , ½ side: 50%, ¼ side: 25% Dernæst tænkte jeg at man kunne oprette en ny tabel til at holde styr på det præcise antal af produkter (Units x Amount), der bliver kørt gennem en transaktion - og hvis en transaktion så annulleres vil man skulle trække data ud fra den igen.
Men er jeg helt på vildspor her? Kunne godt bruge lidt tips til hvordan jeg gør det smartest.. Eventuelle programmeringsproblemer tager jeg bare i en ny tråd, hvis jeg støder på disse undervejs ;)
Det kan vaere at jeg har misforstaaet, men hvis i saelger i enheder mindre end 1, for eksempel kvarte enheder, er det saa ikke blot et spoergsmaal om at aendre datatypen paa 'AmountInStock' fra Integer til Decimal? Naar der saa bestilles 0,25 af en annonceside saa traekkes dette beloeb fra og hvis den bestilling annuleres saa laegges 0,25 til?
umiddelbart tænker jeg at du skal placere "units" i en anden tabel. og så en tabel til at holde styr på typer (1/1, 1/2 og 1/4)
tbl_units ProductId|Amount|UnitTypeId
tbl_unittype UnitTypeId|TypeName
I den tabel kan du så have alle dine tilgængelige helsider til at starte med.
Efterhånden som du får solgt enheder gør du følgende: Hvis enheden du solgte var en 1/4, og der er 1/4 ledig, så fjerner du denne. Er der ikke en ledig, kigger du efter 1/2 enheder og fjerner denne og tilføjer en 1/4. Er der ikke en 1/2 ledig fjerner du en 1/1 og tilføjer en 1/2 og en 1/4. Hvis enheden du solgte var en 1/2, så kigger du efter om der er 1/2, og fjerner denne. Hvis ikke fjerner du en 1/1 og tilføjer en 1/2. Hvis enheden du solgte var en 1/1, så fjerner du blot en sådan.
Idéen er i og for sig fin nok og det ville kunne fungere hvis prisen var ens pr. produkt.. Det forholder sig dog sådan at 1 side er dyrere end to ½-sider osv, så derfor tror jeg desværre ikke man kan gøre det på den måde :S
men det er jo bare et spørgsmål om at du implementerer reglerne for hvordan du fylder dine sider så de afspejler at du hellere vil have solgt hele sider osv.?
hvad med at lave units til den mindste? hvis den mindste er 1/8, så svarer 1 til 1/8 og man skal altså have 8 for at få en hel side? eller er det dumt?
jeg kan heller ikke se, hvorfor du ikke kan bruge decimaler?
Dit oprindelige spoergsmaal, som stillet, drejer sig i realiteten om lager-styring, om antal enheder (hvis du har 10 enheder 'in stock'og du saelger 3 saa har du 7. Hvis 1 returneres har du 8.) Du spoerger saa hvad du skal goere med halve og kvarte enheder. Jeg giver i #1 (og splazz i #6) svaret at du skal definere dine enheder ikke som hele tal men som broekdele/decimaler. Maaske er et bedre at du skal definere 1/4 side, hvis det er det mindste du saelger, som 1 enhed. Hvis du i 'My Fancy Magazine' for februar 2010 har tre sider som du saelger ned til 1/4 side saa har du en tbl_product:
Men i #4 udvider du pludselig spoergsmaalet til at inkludere financiel styring. Ikke alle enheder koster det samme. Saa som 1 side koster mere end 2x 1/2 side (hvilket i oevrigt er usaedvanlig, normalt faar man kvantumrabat, for eksempel 1 liter maelk koster MINDRE end to halv liter.) For at give os en chance for brugbare kommentarer om det kommer du nok til at give os mer information om prisstruktur og hvad du vil opnaa.
Hvad saa, donkarnage, kommer du tilbage til dette spoergsmaal med mer info saa vi har en chance for at hjaelpe? Eller er det i mellemtiden ikke laengere aktuelt?
Det er skam stadig meget aktuelt - jeg havde blot lige glemt at jeg havde denne tråd kørende, så det beklager jeg ;)
I har ret i at det formentlig er nemmest at regne med decimaler/enheder i stedet for. Problemet er bare stadig, som jeg nævnte i #4, at priserne ikke er ens pr. "enhed", så der er også noget financiel styring inde over som du nævner christian_belgien..
Her er et eksempel på deres nuværende priser: 1/1 - side 4995 kr. 1/2 - side 2995 kr. 1/4 - side 1495 kr.
Hvis priserne havde været konstante kunne man så rigtig nok sige: 1/1 - side = 1,0 stk 1/2 - side = 0,5 stk 1/4 - side = 0,25 stk
Og så beregne ud fra disse. Men det kan man desværre ikke, da man ved ovenstående eksempel så ville få en pris på 2497,5 for en halv side.. Så det er lidt derfor jeg har svært ved at se hvordan man lige kan kringle den :/
Det ser for mig ud som om du proever at definere data du ikke kender og ikke kan kende paa det tidspunkt du fylder tabellen. Mens annonceplads er 'paa lager' kan du ikke kende baade antal og pris. Det kan du foerst naar annoncepladsen er solgt og derfor ikke laengere paa lager. Det er det jeg hoerer dig fortaelle. Hvis du har tre sider at fylde kan du definere at det er 12 enheder (kvartsider) som du kan saelge en, to, eller fire ad gangen, men saa kender du ikke enhedsprisen foer de er solgt. Hvis du definerer tre produkter, helside, halvside, og kvartside, saa kan du definere prisen per produkt, men du ved ikke hvor mange du har af hvert produkt. Ikke foer du har solgt dem og derfor ikke laengere har dem. Saa du synes at proeve det umulige.
Yderligere mener jeg at du proever at fylde for mange forskellige data i tbl_produkt. Hvad er dit informationsbehov?
Jeg vil gaette at du har brug for et katalog over produkter. Jeg ville lave en tabel udelukkende med det der ikke forandres gennem et produkts levetid, altsaa:
tbl_product: ProductID | Name | Units | Description | ProductGroupID
Saa har du vel brug for lagerstyring, antallet paa lager.
tbl_product_antal: ProductID | AmountInStock
og saa financiel styring for FORVENTEDE vaerdi af produkterne, forventede fordi du mens produkterne endnu er paa lager maa gaette dig lidt frem.
tbl_product_price: ProductID | Price
Hvis du vaelger i tbl_product at definere annonceplads med Units = 1/4 (hvad jeg vil anbefale hvis det er mindste enhed) saa kunne du i tbl_product_price definere Price = 1495 og saa realisere dig at du giver kvantumrabat hvis du saelger 2 eller 4 enheder paa en gang. Eller du kan definere pris = 1248,75 og saa forvente en ekstra indkomst hvis du saelger dem enkeltvis.
Jeg tillader mig at oprette dette som svar idet jeg mener at have besvaret dit spoergsmaal.
Christian_Belgien: Jeg må indrømme du tabte mig i din sidste kommentar, da du begyndte at snakke om "forventede" produkter og antal :S Men jeg har prøvet mig frem på følgende nu..
tbl_product: ProductID | Name | Price | Description | ProductGroupID
tbl_units: UnitID | AmountInStock | Units | ProductID | UnitGroupID
Når man så opretter/redigerer et produkt kan man vælge om produktet skal være afhængig af andre i en checkboks og dertil kan man angive "størrelsen" på produktet i procent. Hvis produktet er afhængigt af andre bliver "UnitGroupID" sat til at være lig med det produktgruppeID som produktet bliver smidt ind i - og hvis der ingen sammenhæng er bliver "UnitGroupID" blot sat til at være lig med 0..
Men herfra sidder jeg så desværre fast i udregningerne når jeg skal trække X antal produkt fra eller til.. Jeg tænkte lidt at udregningen måtte være:
Nuværende Antal = Nuværende Antal - (100 / størrelsen i procent) * "antal af produkt"
Det kan jeg dog ikke få til at spille med følgende kode:
$queryunits = mysql_query("SELECT * FROM tbl_units WHERE UnitGroupID ='".$_GET['group']."'") or die(mysql_error()); while ($rowunits = mysql_fetch_assoc($queryunits)) { mysql_query("UPDATE tbl_units SET AmountInStock = '".$rowunits['AmountInStock']."' - ((100/'".$rowunits['Units']."') * '".$clean_amount."')") or die(mysql_error()); }
Her får jeg bare nogle tal som jeg ikke helt kan se nogen logik i.. Så har I nogle hints til beregningen når jeg gør det i procent på den her måde? :/
Og du skal selvfølgelig nok få points "Christian_Belgien".. Jeg tænkte blot at jeg lige ville vente, da nogle af de andre nok også gerne ville byde ind med et svar og have en andel af dem ;)
1. Points - det er for mig mindre vigtigt end det at spoergsmaalet paa et eller andet tidspunkt bliver konkluderet og lukket. Man ser her paa Eksperten rigtig mange tilfaelde hvor en spoerger ikke kommer tilbage til sit spoergsmaal men lader det forblive aabent for altid. Derfor har jeg fra tid til anden bedt dig fortaelle hvordan det gaar.
2. Forventede data - ved du paa forhaand om du vil saelge annoncer som helsider, halvsider, eller kvartsider? Hvis ikke, saa kender jeg ikke nogen maade hvor du paa forhaand kan fylde baade antal og priser i en tabel.
3. Jeg kan heller ikke foelge med i logikken i koden #14. Den er for indviklet til min simple hjerne.
4. Det er min erfaring naar jeg er koert fast i et problem at det tit hjaelper at se paa det fra en anden synsvinkel. Du har i denne traad koncentreret dig om HVORDAN du registrerer dataer om produkter og priser. Jeg foreslaar at du tager et frisk kik paa HVAD det er for informationer du til syvende og sidst har brug for og hvad det er for beslutninger du skal tage som informationerne skal hjaelpe dig med. Fortael lidt om din bedrift og dine produkter. Annonceplads, hvordan faar du det til raadighed? Faar du et antal sider til raadighed fra aviser som du saa skal finde kunder til? Eller starter det med kunder der bestiller annoncer som du saa skal finde plads til? Eller, siden du kender de precise priser paa annoncerne skoent priserne vel varierer mellem de forskellige aviser, er det et annonceblad du selv udgiver og hvor annoncepladsen i princippet er ubegraenset? Og hvad skal dine tabeller saa hjaelpe dig med? Hvis du har begraenset annonceplads til raadighed kan jeg for eksempel forestille mig at du vil kunne se hvor meget plads du endnu har til raadighed. Men fortael om HVAD aspekterne, saa kan vi maaske komme frem til bedre forslag paa HVORDAN spoergsmaalene.
1. Ah okay ja. Jeg plejer selv at være flittig i mine tråde, men den her har godt nok drillet mig gevaldigt og gør det stadig :/
2. Nej, det har du selvfølgelig ret i. Man ved dog på forhånd hvor mange sider man har at gøre med i alt.
3. Jeg tror bare jeg skal ha' fundet ud af hvordan regnestykket ser ud når man har en procentdel angivet (af hvor meget det fylder af hele produktet), samt et ønsket antal. Hvis jeg først gør det håber jeg lidt at jeg kan løse problemet :)
4. Dem jeg laver det til har deres eget blad og derfor kender de på forhånd også til side-antallet. Så vidt jeg ved har de derfor også ubegrænset annonceplads. Foruden bladet sælger de også andre forskellige ting, men det er i og for sig kun til bladet at "størrelsesforholdet" er relevant - i hvert fald indtil videre.
Men jeg må prøve at kigge videre på 3'eren i morgen / i dag og se om jeg kan finde en udregning til det..
Hvis du vil at vi skal snakke videre saa er jeg noedt til bedre at forstaa formaalet. Dem du laver det for, hvad er det for beslutninger de skal lave om annonceplads og hvilke informationer skal de bruge for de beslutninger? Hvis vi faar det paa plads saa taenker jeg nok at vi kan finde ud af hvordan det bedst laves. Jeg kan ikke lige gennemskue formaalet med dine indviklede procentberegneinger (og jeg har paa fornemmelsen at det er et vildspor,) derfor er jeg ikke saa ivrig efter at give mig i kast dermed. Hvis du (som du antyder i 3) alligevel vil fokuserer paa det saa foreslaar jeg at du afslutter denne traad og eventuelt starter en ny traad med det spoergsmaal. Det er fjorten dage siden du har haft indlaeg paa denne traad bortset fra mig; med en ny traad faar du frisk opmaerksomhed fra Ekspertens medlemsskare. Hvis du vil dele points saa maa du specifikt bede de der skal have points om at oprette et svar.
Hvis du paa den anden side vil snakke videre her saa har jeg de foelgende punkter:
(1) Du klargjorde at du laver det for nogen der har et blad og som selv bestemmer annonceplads til raadighed. Det hjalp noget.
(2) Saa bestemmer de vel ogsaa mindste annoncestoerrelse. Hvis det er en kvart side saa kan man definere et produkt som en kvartside.
(3) Hvis de i princippet har ubegraenset annonceplads, hvad betyder 'AmountInStock' saa? Er det maaske saaledes at de af hensyn til produktionsplanlaegning maa laegge sig paa et bestemt antal sider for det naeste nummer, for eksempel 10 sider? Hvis det er saaledes saa kan man definere et produkt som 'Annoncer_15.11.2010' og et andet produkt som 'Annoncer_22.11.2010' o.s.v. For hver af disse produkter er AmountInStock 40. Hvis nogen bestiller en helsides annonce, 4 enheder, saa er der 36 paa lager. Hvis det aendres til en halfside-annonce saa foroeges lageret til 38 enheder, o.s.v. Med den information til raadighed kan de se, naar folk bestiller annonceplads, om det stadig er til raadighed.
(4) Hvis de du laver det for ogsaa vil vide hvor meget de kan tjene ved at saelge annoncerne saa maa de se i oejnene at med den prispolitik de har valgt er dette spoergsmaal umuligt at besvare med praecision! De maa saa foretage et valg. Hvis de vaelger konservativt at registrere enhedsprisen lavest muligt, en fjerdedel af helsideprisen, saa vil de normalt faa mere i kassen end den registrerede pris. Hvis de vaelger progressivt at registrere enhedsprisen til kvartsideprisen, saa vil de normalt faa mindre i kassen end den registrerede pris. De kan ogsaa vaelge at registrere enhedsprisen til et gennemsnit.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.