DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Dan ga je weg bij die hosters, maak duidelijk dat je weggaat omdat ze die features niet ondersteunen en dan gaan ze vanzelf wel een keer die meuk ondersteunen.
Of doe zoals ik, huur je eigen doos.
Of doe zoals ik, huur je eigen doos.
In theory there is no difference between theory and practice. In practice there is.
Dat is leuk gezegd, maar je hebt niet altijd invloed op het platform waar je applicatie op wordt geïnstalleerd.quote:Op dinsdag 6 januari 2009 14:56 schreef slacker_nl het volgende:
Dan ga je weg bij die hosters, maak duidelijk dat je weggaat omdat ze die features niet ondersteunen en dan gaan ze vanzelf wel een keer die meuk ondersteunen.
Dat betekend overigens wel dat je hoster geen PHP 5.x draait. Das alleen al reden genoeg om naar een andere hoster over te stappen of te adviseren om te zoeken naar een andere hoster.
In theory there is no difference between theory and practice. In practice there is.
Jij hebt het steeds over hosters, Tijn over platformen. Een hoster host wel op een bepaald platform, maar een platform hoeft nog niet bij een host te horen. Ik heb bijvoorbeeld een klant die naast enkele honderden servers met PHP5 ook nog honderden bakken heeft met PHP4, puur omdat er ook legacy spul op draait (en zo nog meer redenen). Die hebben uiteraard geen host, maar een eigen team van systeembeheerders met daarboven weer architecten. Ik kan nog zo graag PHP5 willen, maar als ik daar op een cluster met PHP4 kom dan breng ik er niets tegeninquote:Op dinsdag 6 januari 2009 16:35 schreef slacker_nl het volgende:
Dat betekend overigens wel dat je hoster geen PHP 5.x draait. Das alleen al reden genoeg om naar een andere hoster over te stappen of te adviseren om te zoeken naar een andere hoster.
Misschien zit PDO dan wel bij PHP 5 standaard, maar wat nou als de hoster het er uit haalt? Doen er ook zat.
En in PHP 6? Er gaan geruchten dat mysql_* en mysqli_* dan niet meer bestaan.... ai daar gaat je website.
Wat doe je dan?
Misschien alleen voor de meer gevorderde, maar je maakt een eigen database-klasse, los van welk database-systeem je hebt. Je kunt hierbij denken aan functies als select(), edit(), count(), insertedID(), etc.. en daar verwerk je een functie in, die je query beveiligd:
array select(string $query, array $variables)
daar kun je het beveiligen, als je PDO hebt is dat simpel, als je geen PDO hebt met mysql_real_escape_string() of intval(), net erna welk type het is.
gaan we nu even kijken:
Je hebt het in PDO gemaakt en je zet het over naar een host zonder PDO...even scriptje omzetten en je hebt het.
Je hebt het met mysql_* gemaakt en je wilt het in PDO hebben, want je wilt overgaan naar PHP 6...even scriptje omzetten.....
zie je? veel handiger
Hopelijk hebben sommigen er iets aan
mvg
Marco
Dit bericht is niet gericht op een persoon, maar als algemene informatie als toevoeging bij het huidige onderwerp. Eventuele opmerkingen die je persoonlijk kunt opvatten moet je zo dus niet opvatten.
En in PHP 6? Er gaan geruchten dat mysql_* en mysqli_* dan niet meer bestaan.... ai daar gaat je website.
Wat doe je dan?
Misschien alleen voor de meer gevorderde, maar je maakt een eigen database-klasse, los van welk database-systeem je hebt. Je kunt hierbij denken aan functies als select(), edit(), count(), insertedID(), etc.. en daar verwerk je een functie in, die je query beveiligd:
array select(string $query, array $variables)
daar kun je het beveiligen, als je PDO hebt is dat simpel, als je geen PDO hebt met mysql_real_escape_string() of intval(), net erna welk type het is.
gaan we nu even kijken:
Je hebt het in PDO gemaakt en je zet het over naar een host zonder PDO...even scriptje omzetten en je hebt het.
Je hebt het met mysql_* gemaakt en je wilt het in PDO hebben, want je wilt overgaan naar PHP 6...even scriptje omzetten.....
zie je? veel handiger
Hopelijk hebben sommigen er iets aan
mvg
Marco
Dit bericht is niet gericht op een persoon, maar als algemene informatie als toevoeging bij het huidige onderwerp. Eventuele opmerkingen die je persoonlijk kunt opvatten moet je zo dus niet opvatten.
Ik denk dat velen hier al een dergelijke abstractielaag gebruiken (zelf geschreven, of omdat ze een framework gebruiken) Niettemin een prima tip!
Niettemin een prima tip!
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!!
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!!
Ik zou gaan voor optie twee, al zijn product_naam en product_gewicht natuurlijk enigzins redundante datum en zou je als een product wijzigt eigenlijk een nieuw product moeten toevoegen aan de database en het oude product een 'niet actief' tag mee moeten geven.
Maar dat hangt van je hele datamodel af.
Maar dat hangt van je hele datamodel af.
Weet iemand zo even uit zijn mouw te schudden hoe je middels een query (mysql) gebruikers kunt vinden waarbij de gebruikersnamen beginnen met een cijfer (0-9). Met letters lukt simpel LIKE 'B%' maar ik wil nu alle gebruikers die gebruikersnamen hebben met 0-9
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Geen idee, ik ben niet zo goed in regular expressions. Of zit ik helemaal fout met dat 'ie REGEXP moet gebruiken?quote:
met REGEXP in MySQLquote:Op donderdag 8 januari 2009 11:17 schreef Chandler het volgende:
Weet iemand zo even uit zijn mouw te schudden hoe je middels een query (mysql) gebruikers kunt vinden waarbij de gebruikersnamen beginnen met een cijfer (0-9). Met letters lukt simpel LIKE 'B%' maar ik wil nu alle gebruikers die gebruikersnamen hebben met 0-9
=edit=
casten levert teveel 0-en op
Ik deed bijdehand met het noemen van het veld 'lala' verder zou ik het niet weten en ben ik een regexp n00b.
Werkt idd perfect, had zelf een andere versie met % maar dat werkte natuurlijk nietquote:
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Je kunt denk ik ook WHERE veld BETWEEN '0' and '9' gebruiken. Als het werkt, kan het in ieder geval gebruik maken van indices, hoewel ik niet denk dat je daar winst mee boekt tenzij er weinig gebruikers zijn die hun username met een getal laten beginnen.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Nee dus.quote:Op donderdag 8 januari 2009 11:36 schreef GlowMouse het volgende:
Je kunt denk ik ook WHERE veld BETWEEN '0' and '9' gebruiken.
'9adsf' gaat foutquote:
Kun je nog >='0' AND <':' gebruiken.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ik zou voor het eerste gaan om de volgende reden: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!!
Als de naam van je product (typo) of prijs verandert, en je hebt een link naar je productnummer, wordt da overal weer correct aangepast. Afhankelijk van de situatie wil je dan de prijs wel/niet aanpassen. Ik denk dat je in zon geval bij bestellingen de prijs aan wil passen, en als een bestelling betaald is (dan is het ook geen bestelling meer maar een factuur) dat je alles wil fixeren.
Data redundant opslaan blijft imo
tenzij het duidelijke voordelen heeft. In dit geval zie ik het voordeel totaal neit. Het scenario wat jij schets met producten die verwijderd zijn zou ik oplossen door producten niet uit je database te gooien (is sowieso een slecht idee ivm commercie), maar door ze inactief te maken. En natuurlijk kan je na x jaar je productentabel opschonen door alle inactieve dingen van meer dan x jaar oud weg te gooien.
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.
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 ookquote: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.
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.
Dat dus. Bestellingen != Facturen, en daar moet je in je database al rekening mee hebben gehouden.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.
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.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.
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.
En hoe wil jij de bestelgeschiedenis van iemand gaan bijhouden dan met optie 1?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.
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.
Een persoon heeft 0 of meer facturen, een factuur heeft 1 of meer producten. Tadaamquote: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?
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.
Maar denk dat het per situatie wel kan schelen welke de beste insteek heeft.
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: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.
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.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.
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.
Het gaat mij meer om de naam, gewicht, beschrijving etc.
Bestelling_nr , Klant_nummer, Productnummer, Product_naam,product_gewicht, Prijsquote: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!!
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
orders kunnen ook anders worden weergegeven.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)
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 ]
Redacted
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
Heb dat nog nooit gedaan en wil daar toch es mee aan de slag
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
PHP kan dat nietquote: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
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.
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: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.
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Ja, gratis is er sowieso weinig anders te vinden op dit gebied.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?
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?
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..
| 1 |
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?
Dat bedacht ik me na het posten ook, het ziet er in ieder geval beter uit voor de queries die ik gebruik.
Tijd voor een lesje datatypes voor beginnersquote: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'.
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.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).
Maar voor booleans zal ik dan voortaan wel 0 en 1 gebruiken
.[ Bericht 8% gewijzigd door Gloeidoos op 09-01-2009 15:33:50 ]
Zou voor geen van die beide gaan... zou voor het volgende gaan...quote:
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!!
- 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.
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 ]
| 1 2 3 4 5 | FROM a JOIN b USING (naam) WHERE b.enabled = 'Y'; |
Kan je mij uitleggen wat er beter is aan:quote:Op vrijdag 9 januari 2009 14:58 schreef HuHu het volgende:
Wat je nu doet is hetzelfde als:
[ code verwijderd ]
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';
?
In theory there is no difference between theory and practice. In practice there is.
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:
[..]
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';
?
En ik vind het ook een stuk leesbaarder.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.
