Ja ok, maar hoe zit dat dan met de queries zelf? Moet je dan niet alsnog bepaalde syntax zoals LIMIT...OFFSET aanpassen voor postgres?quote:Op zaterdag 4 oktober 2014 20:04 schreef Rockfire het volgende:
[..]
Ik heb het al degelijk wel eens meegemaakt. Switchen van database (van MySQL naar Postgres) en helaas was er geen gebruik gemaakt van PDO
Jawel, maar als dat alles is is het veel minder werk dan ook nog de code ombouwen naar PDO-gebruikquote:Op zaterdag 4 oktober 2014 20:08 schreef mstx het volgende:
[..]
Ja ok, maar hoe zit dat dan met de queries zelf? Moet je dan niet alsnog bepaalde syntax zoals LIMIT...OFFSET aanpassen voor postgres?
In principe heb je gelijk, maar het ligt er ook aan hoe de applicatie is opgebouwd. Ik maak nu zelf gebruik van mysqli maar ik zou het in een paar minuten kunnen ombouwen naar PDO of iets anders omdat ik het gewoon in een database-classje heb zitten dus ik hoef maar een paar functies aan te passen.quote:Op zaterdag 4 oktober 2014 20:09 schreef Rockfire het volgende:
[..]
Jawel, maar als dat alles is is het veel minder werk dan ook nog de code ombouwen naar PDO-gebruik
Dat regelt de ORM voor ons. Whieeee.quote:Op zaterdag 4 oktober 2014 20:08 schreef mstx het volgende:
[..]
Ja ok, maar hoe zit dat dan met de queries zelf? Moet je dan niet alsnog bepaalde syntax zoals LIMIT...OFFSET aanpassen voor postgres?
Tot op heden geen probleem, maar die kunnen nog komen hoorquote:Op donderdag 2 oktober 2014 21:55 schreef KomtTijd... het volgende:
InnoDB tabellen zou je als het goed is niet moeten kunnen kopiëren door de bestanden in het filesystem te kopiëren. Althans, misschien kan het goed gaan maar het wordt uitdrukkelijk afgeraden en niet ondersteund.
Zoals gezegd, kijk eerst waar de bottleneck precies ligt. Alles in MySql proppen is ook niet ideaal, zeker niet als je later besluit om nog eens van Database technologie te wisselen. Het zou bijvoorbeeld ook best kunnen zijn dat het handiger is om hier een back-end service voor in te richten. PHP is niet bepaald optimaal voor zware berekeningen en daarbij kun je met een dergelijke oplossing gebruik maken van caching. Bovendien is het non-blocking, oftewel, de gebruiker hoeft er niet op te wachten. Een andere oplossingsrichting is bijvoorbeeld het gebruik maken van web workers om in de browser asynchroon iets te laten uitvoeren.quote:Op maandag 6 oktober 2014 23:22 schreef TwenteFC het volgende:
Gewoon even omdat ik graag van input van anderen hou,
Hoe zouden jullie de volgende situatie aanpakken;
Een groothandel met een ~10,000 klanten die regelmatig wat bestellen uit een assortiment van 60,000 producten die zijn onderverdeeld in ongeveer 150 categorieën.
Waarbij er per klant/inkoopgroep korting gegeven kan worden complete groepen, individuele producten, staffelkorting, uitzonderingen binnen groepen waarop geen korting gegeven mag worden, actie periodes waarvoor een andere prijs geldt, kortingen vanaf een bepaald bedrag en kortingen die zowel als een prijsafspraak of als een percentage kunnen worden gegeven en combinaties hiertussen.
Dit werkt op dit moment allemaal nog "on the fly" maar ik merk zelf dat de performance wanneer bijvoorbeeld gechecked moet worden op staffelkortingen die gegeven worden op een combinatie van een merk en een groep niet is wat het zou moeten zijn.
Is het een gek idee om kortingen voor een klant op het moment van het aanmaken van een regel,en bij het wijzigen / aanmaken van een product wordt gecontroleerd of er klanten zijn die in aanmerkingen komen voor korting. op te slaan in een database, zodat deze berekeningen niet constant in de winkelwagen, bij wijze van hoeven plaats te vinden?
Als eerste zou ik uitzoeken waarom die berekeningen zo lang duren en of er niet wat te optimaliseren valt.quote:Op maandag 6 oktober 2014 23:22 schreef TwenteFC het volgende:
Gewoon even omdat ik graag van input van anderen hou,
Hoe zouden jullie de volgende situatie aanpakken;
Een groothandel met een ~10,000 klanten die regelmatig wat bestellen uit een assortiment van 60,000 producten die zijn onderverdeeld in ongeveer 150 categorieën.
Waarbij er per klant/inkoopgroep korting gegeven kan worden complete groepen, individuele producten, staffelkorting, uitzonderingen binnen groepen waarop geen korting gegeven mag worden, actie periodes waarvoor een andere prijs geldt, kortingen vanaf een bepaald bedrag en kortingen die zowel als een prijsafspraak of als een percentage kunnen worden gegeven en combinaties hiertussen.
Dit werkt op dit moment allemaal nog "on the fly" maar ik merk zelf dat de performance wanneer bijvoorbeeld gechecked moet worden op staffelkortingen die gegeven worden op een combinatie van een merk en een groep niet is wat het zou moeten zijn.
Is het een gek idee om kortingen voor een klant op het moment van het aanmaken van een regel,en bij het wijzigen / aanmaken van een product wordt gecontroleerd of er klanten zijn die in aanmerkingen komen voor korting. op te slaan in een database, zodat deze berekeningen niet constant in de winkelwagen, bij wijze van hoeven plaats te vinden?
Das wel balen, anders had het in principe alleen een nieuwe handler gekost.quote:Op zaterdag 4 oktober 2014 20:04 schreef Rockfire het volgende:
[..]
Ik heb het al degelijk wel eens meegemaakt. Switchen van database (van MySQL naar Postgres) en helaas was er geen gebruik gemaakt van PDO
1 | <p>{$prompt_destname} <input type="text" name="{$actionid}input_destname" value="" size="40" maxlength="255"/></p> |
1 | {current_date format="%y%m%d%T"} |
Misschien is de engelse helppage wat duidelijker, mocht je er niet uit komen.quote:(optional) prefix="0" - Een boolean die aangeeft of bestandsnamen een prefix moeten hebben
(optional) prefix_feu="0" - Een boolean parameter die aangeeft dat de prefix van de huidige auteur gebruikt moet worden of, als deze niet opgegeven is, de prefix van de huidige tijd (in dechex formaat)
Noem het dan gewoon has_prefix, prefix_author, dan is het in een keer duidelijk. Naamgeving van dingen.. blergh.quote:Op woensdag 8 oktober 2014 13:12 schreef KomtTijd... het volgende:
uit de documentatie van de uploads module:
[..]
Misschien is de engelse helppage wat duidelijker, mocht je er niet uit komen.
Het is ook niet naar jou toe hoor. Ik zie het in onze eigen code base ook. Ding krijgt een naam ala: user_id terwijl we het over een haar_kleur_id hebben. Argh! Dan heb ik liever dat ze het foo noemen.quote:Op woensdag 8 oktober 2014 13:36 schreef KomtTijd... het volgende:
Ik denk eerder dat de omschrijvingen gewoon brak vertaald zijn, geen zin om het weer te checken gezien dat met 10 seconden trial-and-error ook wel vast te stellen valt.
Van myVar1 t/m myVar392 en myTemporaryVar1 t/m myTemporaryVar921 word ik meestal ook niet echt vrolijk. Eén van de redenen dat ik blij ben dat ik nauwelijks meer met PHP developers te maken heb.quote:Op woensdag 8 oktober 2014 14:00 schreef slacker_nl het volgende:
[..]
Het is ook niet naar jou toe hoor. Ik zie het in onze eigen code base ook. Ding krijgt een naam ala: user_id terwijl we het over een haar_kleur_id hebben. Argh! Dan heb ik liever dat ze het foo noemen.
Dit speelt natuurlijk niet alleen onder PHP-developers, hequote:Op woensdag 8 oktober 2014 15:04 schreef Monolith het volgende:
[..]
Van myVar1 t/m myVar392 en myTemporaryVar1 t/m myTemporaryVar921 word ik meestal ook niet echt vrolijk. Eén van de redenen dat ik blij ben dat ik nauwelijks meer met PHP developers te maken heb.
Nee, maar de kracht van PHP is echter dat het simpel en laagdrempelig. Dat is ook gelijk het probleem. Bijna iedere debiel kan er mee werken en helaas doen ook veel te veel debielen dat.quote:Op woensdag 8 oktober 2014 15:24 schreef Tijn het volgende:
[..]
Dit speelt natuurlijk niet alleen onder PHP-developers, he
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Ik zal je mijn code verder besparen danquote:Op woensdag 8 oktober 2014 15:35 schreef Tijn het volgende:
Ik heb wel het idee dat het mede dankzij de toolset van vandaag de dag (Composer, Symphony etc.) en de ontwikkelingen in de taal (deprecaten van mysql_ functies enzo) de laatste tijd wat beter gesteld is.
Maar om eerlijk te zijn zie ik eigenlijk niet zoveel PHP-code van anderen om echt een idee te hebben van wat mensen over het algemeen doen
Of van die mensen die constant bestaande variabelen OPNIEUW in een andere zetten en dan er uiteindelijk niks mee doenquote:Op woensdag 8 oktober 2014 15:04 schreef Monolith het volgende:
[..]
Van myVar1 t/m myVar392 en myTemporaryVar1 t/m myTemporaryVar921 word ik meestal ook niet echt vrolijk. Eén van de redenen dat ik blij ben dat ik nauwelijks meer met PHP developers te maken heb.
1 2 3 4 | <?php $name = $_POST['name']; echo $name; //WAAAAAAAAAAAAAAAAAAAAAAAAAAAAROM!!!!! |
Voor de wat grotere projecten wel ja, maar het neemt niet weg dat PHP in de basis nog steeds heel beroerd ontworpen is. Zie bijvoorbeeld deze vermakelijke klaagzang.quote:Op woensdag 8 oktober 2014 15:35 schreef Tijn het volgende:
Ik heb wel het idee dat het mede dankzij de toolset van vandaag de dag (Composer, Symphony etc.) en de ontwikkelingen in de taal (deprecaten van mysql_ functies enzo) de laatste tijd wat beter gesteld is.
Maar om eerlijk te zijn zie ik eigenlijk niet zoveel PHP-code van anderen om echt een idee te hebben van wat mensen over het algemeen doen
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |