[PHP/(My)SQL] voor dummies - Deel 66

quote:

Op donderdag 8 januari 2009 13:43 schreef Roy_T het volgende:
Ik zou het wel redundant opslaan, en dezelfde tabel gebruiken voor "bestellingen" en "facturen". Het is namelijk precies hetzelfde, alleen is bij de ene "payed" false en bij de andere true.

Waarom zou je de prijs aan willen passen nadat een product besteld is maar nog niet geleverd? Stel dat je iets bestelt voor 10 euro, 10 minuten later maakt de admin dat product 20 euro en wanneer de bestelling wordt afgehandeld is de klant opeens het dubbele kwijt.

Data redundant opslaan lijkt me in dit geval een duidelijk voordeel hebben: het is 100% gelijk aan het moment waarop er besteld werd.

Ik zou overigens wel een aparte tabel maken voor orders (dus bestellingen), met hierin het klantnummer, afleveradres, status, etc. en een tabel met order_items (ofzo) die weer aan orders hangen.

Ja, dat doe ik inderdaad ook

Ziet er ongeveer zo uit:

orders (order_id, klant_id, opmerkingen, timestamp)
orders_items, (item_id, order_id, naam, prijs, opmerkingen)
orders_gegevens (order_ID, factuur_adres, leverings_adres)


Ik denk ook dat optie 2 het beste is, ben er normaal ook voorstander van dingen slechts éénmaal op te slaan, maar het is dan maar niet anders.... als er iets wijzigt is dat erg raar dat zoiets in je bestelgeschiedenis ook wordt doorgevoerd.

Als een product wordt aangepast wegens een typfout, ja dan zou het wel mooi zijn als het overal kan worden doorgevoerd.....maar dat is niet nodig in dit geval.

quote:

Op donderdag 8 januari 2009 13:43 schreef Roy_T het volgende:
Waarom zou je de prijs aan willen passen nadat een product besteld is maar nog niet geleverd? Stel dat je iets bestelt voor 10 euro, 10 minuten later maakt de admin dat product 20 euro en wanneer de bestelling wordt afgehandeld is de klant opeens het dubbele kwijt.

Besteld (dus in je winkelwagen) maar nog niet betaald, dan betaal je gewoon de actuele prijs. Volgens mij is dat gebruikelijk. Kijk maar naar amazon of bol. Als iets in je winkelwagen zit, maar nog niet betaald is.
Daarnaast is een factuur niet hetzelfde als een bestelling wat betaald is aangezien een factuuradres anders kan zijn dan het bezorgadres.
Sterker nog, real life is een bestelbon ook geen factuur en als je gaat modelleren wil je dat soort nuances ook in je model hebben. En tuurlijk er zijn altijd wel hacks te bedenken om twee verschillende beestjes een te maken (of andersom), maar omdat het kan en omdat het werkt wil het nog niet zeggen dat het goed is.
Stel je gaat naar een winkel en plaatst een bestelling wat je over 5 dagen op kan komen halen. Je komt na 5 dagen je bestelling halen. De winkelier kan voor zijn eigen gemak en voor het milieu geen factuur maken maar jou bestelbon ondertekenen en erbij zetten dat het betaald is. Dat gebeurt toch ook niet..? En fraudegevoeligheid is echt niet de belangrijkste reden.

quote:

Op donderdag 8 januari 2009 15:44 schreef Scorpie het volgende:

[..]

En hoe wil jij de bestelgeschiedenis van iemand gaan bijhouden dan met optie 1?

Een persoon heeft 0 of meer facturen, een factuur heeft 1 of meer producten. Tadaam
Op het moment dat iemand zijn bestelling heeft betaald wordt de bestelling weggegooid en wordt het een factuur. En in de factuur is naam & prijs wel gefixeerd.

Ik ben het met jullie eens dat optie 2 de makkelijke manier is, maar optie 1 levert een meer waarheidsgetrouw model op.

Zoiets sla je stapsgewijs elke keer op. Je wilt toch niet een klant een product t.w.v. 10 euro in zijn winkelwagen laten stoppen, om het vervolgens door diezelfde klant te laten bestellen terwijl het 'opeens' 12 euro kost, om het ten slotte door die klant te laten afrekenen terwijl het 'opeens' 14 euro kost.

Daarnaast kan een bestelling ook wel eens gezien worden als offerte, welke vaak weer een duur van 14 dagen heeft ofzo. Dus als jij je prijs verhoogt, heeft de klant nog steeds recht op die prijs.

Maar denk dat het per situatie wel kan schelen welke de beste insteek heeft.

quote:

Op donderdag 8 januari 2009 15:41 schreef Database het volgende:

Besteld (dus in je winkelwagen) maar nog niet betaald, dan betaal je gewoon de actuele prijs. Volgens mij is dat gebruikelijk. Kijk maar naar amazon of bol. Als iets in je winkelwagen zit, maar nog niet betaald is.
Daarnaast is een factuur niet hetzelfde als een bestelling wat betaald is aangezien een factuuradres anders kan zijn dan het bezorgadres.

Dan is een "bestelling" voor ons beiden iets anders. Ik zou pas een "bestelling" van iets maken wanneer de order geplaatst wordt, en het tot die tijd alleen in de sessie of tijdelijk in een aparte tabel ofzo zetten.

quote:

Sterker nog, real life is een bestelbon ook geen factuur en als je gaat modelleren wil je dat soort nuances ook in je model hebben. En tuurlijk er zijn altijd wel hacks te bedenken om twee verschillende beestjes een te maken (of andersom), maar omdat het kan en omdat het werkt wil het nog niet zeggen dat het goed is.

Ik vind het geen hack. Je kunt wel alles naar real life willen modeleren, maar soms (en imo in dit geval) kun je hierbij gelukkig dingen die in real life niet kunnen. Jij hebt het over bestelbonnen en facturen, ik gewoon over "orders". En die zijn betaald of niet betaald (of hebben een andere status, zoals "wacht op akkoord" of whatever), en op basis van die status kun je een bestelbon, afleverbon, retourbon, RMA-formulier of een factuur genereren. Dat je in de supermarkt een bonnetje krijgt, wil niet zeggen dat er in hun boekhouding allemaal "bonnetjes" zitten. Dat zijn gewoon verkopen/orders, waarbij het bonnetje één van de vele mogelijke representaties van die order is.

Even voor de duidelijkheid, ik neem aan dat er in allebei de voorbeelden de prijs natuurlijk standaard zit.
Het gaat mij meer om de naam, gewicht, beschrijving etc.

quote:

Op donderdag 8 januari 2009 07:29 schreef jeroen2497 het volgende:
Ik heb een vraag mbt de bouw van een webshop.

Hoe zouden jullie de data van een bestelling in de database opnemen?

Een tabel met;
- klant_nummer, product_nummer, prijs
- klant_nummer, product_nummer, product_naam, product_gewicht, prijs

Het voordeel van optie 2 is dat als er een productnaam wordt gewijzigd (of zelfs verwijderd), dat alle info wel in de bestelling blijft staan.

Het gaat om flink wat bestellingen per dag.
Graag jullie idee hier over!!

Bestelling_nr , Klant_nummer, Productnummer, Product_naam,product_gewicht, Prijs

primaire sleutel is bestelling_nr
dit zodat een klant vaker 1 artikel kan bestellen.

als je het helemaal mooi wil hebben;
Facturen
factuur_nr, Klant_nummer,gewenste_leverdatum,min_leverdatum,totaal_prijs, status ,betaald
(ontvangen , niet ontvangen)

verkooporder regel
factuur_nr , Productnummer, Product_naam,aantal,product_gewicht, Prijs

quote:

orders (order_id, klant_id, opmerkingen, timestamp)
orders_items, (item_id, order_id, naam, prijs, opmerkingen)
orders_gegevens (order_ID, factuur_adres, leverings_adres)

orders kunnen ook anders worden weergegeven.

order ( order_id, klant_nr,lever_adres,gewenste_leverdatum, bestelde_datum, status)
orderregel ( order_id , item_id ,omschrijving, aantal , prijs ,opmerkingen)

Prijs zet je op order regel zodat de klant niet na afloop duurder hoeft te betalen of goedkoper!
dit om misverstanden te voorkomen.

btw prijs is de prijs die op het moment van bestellen is gebruikt en niet zoals het in het artikelbestand staat

en als ze verwerkt zijn update je ze naar het archief ( simpel php code + query aan vastzetten , ideale oplossing om verwerkte orders in op te slaan.)

archief_order()
archier_orderregel () zelfde velden

[ Bericht 5% gewijzigd door cablegunmaster op 08-01-2009 18:30:32 ]

Is er ook iemand die tips heeft m.b.t. uploaden en converteren naar .FLV van filmpjes m.b.v. PHP? Ik las op het grote internet dat Ffmpeg daarvoor het meest geschikt zou zijn - iemand die dat kan bevestigen?
Heb dat nog nooit gedaan en wil daar toch es mee aan de slag

quote:

Op vrijdag 9 januari 2009 10:02 schreef LordNemephis het volgende:
Is er ook iemand die tips heeft m.b.t. uploaden en converteren naar .FLV van filmpjes m.b.v. PHP? Ik las op het grote internet dat Ffmpeg daarvoor het meest geschikt zou zijn - iemand die dat kan bevestigen?
Heb dat nog nooit gedaan en wil daar toch es mee aan de slag

PHP kan dat niet Je zal daar dus een programma als Ffmpeg (geen idee of die dat kan) voor moeten gebruiken die je aanroept vanuit je PHP.

FFMpeg is niet het beste programma om video's mee te recoden, maar het is in elk geval wel gratis en ondersteunt veel formaten. Je kunt het vanuit PHP makkelijk aanroepen omdat het een command line programma is.

quote:

Op vrijdag 9 januari 2009 11:02 schreef Tijn het volgende:
FFMpeg is niet het beste programma om video's mee te recoden, maar het is in elk geval wel gratis en ondersteunt veel formaten. Je kunt het vanuit PHP makkelijk aanroepen omdat het een command line programma is.

Ik weet dat PHP op zichzelf geen video's kan converteren. Ik zocht idd naar een OpenSource oplossing (lees: graties). Ffmpeg is dus wel een aanrader voor mij?

quote:

Op vrijdag 9 januari 2009 11:31 schreef LordNemephis het volgende:

[..]

Ik weet dat PHP op zichzelf geen video's kan converteren. Ik zocht idd naar een OpenSource oplossing (lees: graties). Ffmpeg is dus wel een aanrader voor mij?

Ja, gratis is er sowieso weinig anders te vinden op dit gebied.

Heb weer eens een query vraagje.

Stel ik heb in tabel a een kolom 'naam'. In tabel b is de primary key deze 'naam'. Verder staat in tabel b nog een kolom 'enabled' met de waarde 'Y' of 'N'.

Als ik nu een query wil loslaten op a waarvoor geldt dat de 'enabled' op 'Y' staat in tabel b..



Dit werkt, maar het kan volgens mij ook met een join. Zouden jullie dit ook met een join doen, of zie ik nog een andere oplossing over het hoofd?

Wat je nu doet is hetzelfde als:

Dat bedacht ik me na het posten ook, het ziet er in ieder geval beter uit voor de queries die ik gebruik.

quote:

Op vrijdag 9 januari 2009 14:55 schreef Gloeidoos het volgende:

Stel ik heb in tabel a een kolom 'naam'. In tabel b is de primary key deze 'naam'. Verder staat in tabel b nog een kolom 'enabled' met de waarde 'Y' of 'N'.

Tijd voor een lesje datatypes voor beginners

Wat jij wilt is een boolean, en die sla je normaliter in een MySQL database op als integer met de waarde 1 (true) of 0 (false).

quote:

Op vrijdag 9 januari 2009 15:18 schreef Roy_T het volgende:

[..]

Tijd voor een lesje datatypes voor beginners

Wat jij wilt is een boolean, en die sla je normaliter in een MySQL database op als integer met de waarde 1 (true) of 0 (false).

Ik heb de tables aangepast om het een beetje simpel te houden. In feite is het een kolomnaam met de naam state, enum('enabled','disabled'). Volgens mij komen hier uiteindelijk nog meer states bij, als dat nodig is.

Maar voor booleans zal ik dan voortaan wel 0 en 1 gebruiken .

[ Bericht 8% gewijzigd door Gloeidoos op 09-01-2009 15:33:50 ]

quote:

Op donderdag 8 januari 2009 07:29 schreef jeroen2497 het volgende:
Ik heb een vraag mbt de bouw van een webshop.

Hoe zouden jullie de data van een bestelling in de database opnemen?

Een tabel met;
- klant_nummer, product_nummer, prijs
- klant_nummer, product_nummer, product_naam, product_gewicht, prijs

Het voordeel van optie 2 is dat als er een productnaam wordt gewijzigd (of zelfs verwijderd), dat alle info wel in de bestelling blijft staan.

Het gaat om flink wat bestellingen per dag.
Graag jullie idee hier over!!

Zou voor geen van die beide gaan... zou voor het volgende gaan...
- klant_nummer, product_nummer, status

product_nummer, product_naam, product_gewicht en prijs zijn namelijk zaken die allemaal gerelateerd zijn aan het product waar je dus een aparte tabel voor hebt...

en p.s. in status moet je dan bijvoorbeeld bij denken, in behandeling, verzonden, ontvangen etc... kortom de stappen die jou product maakt tot het bij de klant is.

quote:

Op vrijdag 9 januari 2009 14:58 schreef HuHu het volgende:
Wat je nu doet is hetzelfde als:
[ code verwijderd ]

Of, nog een andere optie:

quote:

Op vrijdag 9 januari 2009 14:58 schreef HuHu het volgende:
Wat je nu doet is hetzelfde als:
[ code verwijderd ]

Kan je mij uitleggen wat er beter is aan:

select * from a,b where a.id = b.pid and b.bla = 'Y';

en

select * from a join b on a.id = b.pid where b.bla = 'Y';

?

quote:

Op vrijdag 9 januari 2009 17:21 schreef slacker_nl het volgende:

[..]

Kan je mij uitleggen wat er beter is aan:

select * from a,b where a.id = b.pid and b.bla = 'Y';

en

select * from a join b on a.id = b.pid where b.bla = 'Y';

?

Die tweede vorm is veel efficienter. Je geeft daar meteen aan hoe gejoind moet worden in de on clause, en daardoor kan de query beter geoptimaliseerd worden.

quote:

Op vrijdag 9 januari 2009 18:10 schreef Farenji het volgende:

[..]

Die tweede vorm is veel efficienter. Je geeft daar meteen aan hoe gejoind moet worden in de on clause, en daardoor kan de query beter geoptimaliseerd worden.

En ik vind het ook een stuk leesbaarder.