[Alg] Welke programmeertaal gebruiken?

[Verwijderd]

Om maar meteen met de deur in huis te vallen: Ik heb 0,0 procent verstand van (web)programming, en verder dan het opzetten van een pagina met een paar regels HTML (met behulp van een spiekbriefje ), kom ik niet. Echter, ik heb wel een (naar mijn mening) goed idee dat ik graag zou willen zien worden uitgewerkt.

Ik ben van plan om de ontwerp/ontwikkeling van de website die daarbij benodigd zal zijn, uit te besteden. Daar mijn financiele middelen beperkt zijn, zou ik dit graag door ervaren hobbyisten of semi-professionals laten doen. Mijn vraag aan jullie is echter: welke 'programmeertaal' (ik weet niet of dat de correcte omschrijving is; ik heb het over PHP, ASP, etc.) kan hiervoor het beste gebruikt worden, zodat ik weet wat voor eisen ik kan stellen aan de ontwikkelaar? En welke producten zijn hiervoor nodig (SQL... welke?)?

Alhoewel ik jullie niet te veel kan vertellen (ik wil niet dat iemand met mijn ideeen aan de haal gaat ), zal ik toch een tipje van de sluier moeten lichten. Ik zal derhalve proberen de opzet kort doch duidelijk te omschrijven.

-----

Stel een bedrijf heeft een aantal producten (prod. 1, prod. 2, prod. 3, etc.) die ze wil verkopen, en deze producten zijn onder te verdelen in verschillende categorieen (cat. 1, cat. 2, cat. 3, etc.). Deze producten worden door het bedrijf op internet aangeboden, via een tussenpersoon. Het bedrijf voorziet de tussenpersoon van productinformatie, en de tussenpersoon zorgt ervoor dat de informatie bij de juiste klanten terechtkomt via e-mail.

Het aantal producten waar een klant via e-mail informatie over ontvangt, hangt af van de productcategorieen en/of individuele producten waarin de klant is geinteresseerd. Deze voorkeur is door de klant eerder aan de tussenpersoon bekendgemaakt d.m.v. een 'webformulier', waarin hij aangaf welke producten en/of productsoorten hem aanspreken. De klant gebruikt dit formulier om aan te geven over welke productcategorieen en/of individuele producten hij informatie wenst te ontvangen.

-----

Wat ik dus in gedachten heb is het volgende:

1. Een bedrijf schrijft zich in bij de tussenpersoon ('maakt een account aan'), en voorziet deze van informatie omtrent de producten die het bedrijf aanbiedt. Deze informatie wordt bij voorkeur via een zgn. 'webformulier' verstrekt aan de tussenpersoon.

2. Een klant schrijft zich ook in bij het tussenbedrijf, en vult tegelijk een soortgelijk 'webformulier' in, waarin hij aangeeft welke producten en/of productcategorieen hem aanspreken. Zodra er meer informatie over dit product bekend wordt, of als er iets aan het product verandert (prijs bijvoorbeeld), krijgt de klant deze informatie via e-mail toegestuurd.

3. Daar deze informatie via e-mail wordt verstuurd, moet het dus mogelijk zijn dat de tussenpersoon de 'productinformatie-database' kan koppelen aan de 'voorkeuren-database' van de klant.

Mijn vraag is dus: welke 'programmeertaal' is hiervoor nodig en/of wordt door jullie aanbevolen? Ik heb zelf een lichte voorkeur voor PHP/MySQL, gezien het feit dat dit kostentechnisch een prima oplossing lijkt. Echter, kun je er bij PHP voor zorgen dat automatisch een e-mailtje wordt verstuurd wanneer er informatie aan de 'productinformatie-database' wordt toegevoegd, gebaseerd op de selectie van de klant?

Ik wacht maar af of er reacties komen... mochten jullie meer info nodig hebben, dan hoor ik het wel (hoop ik). Maar zoals gezegd... ik kan ook weer niet al te veel vertellen!

Alvast bedankt!

[drm]

---

Replies goed onderbouwen aub!

---

[whoami]

Use the right tool for the right job.

Er zijn verschillende tools beschikbaar voor webapplicaties te maken. PHP, ASP, ASP.NET, ... Alhoewel dat ASP 'a dead end' is, en zal vervangen worden door ASP.NET.

Alle tools hebben voordelen en nadelen, zo is ASP.NET bv. volledig OO, gecompileerd, .... maar zal het wellicht langer duren om het te ontwikkelen dan in bv. PHP, dat dan weer niet type - safe is, niet OO is, ...

Wat je ook nodig zult hebben, is een databank om je gegevens in op te slaan. Welke db je wilt gebruiken, hangt (net als de taal trouwens) af van de prijs die je wilt betalen. MySQL is gratis, net als PostgresSQL.
SQL Server, Oracle, DB2 etc... zijn dan weer commerciële dbms'en die niet goedkoop zijn.

[Glock]

PHP is prima in staat tot wat jij beschrijft, en blijkbaar heb je al een keuze gemaakt.

De PHP Manual heeft een zeer duidelijke uitleg en is makkelijk te leren voor een beginner, echter zo heeft iedereen ook weer zijn voorkeuren.
Zo heb je ook weer ASP voorstanders, je kan het beste kijken van wat jou het beste lijkt of het makkelijkst. Bij zo'n topic als dit krijg je 9 uit de 10 keer dat iedereen 'zijn' programmeertaal gaat lopen aanprijsen en wat je dus ook niet verder helpt. Proberen lijkt me een handige optie

_{My €0.02}

edit:
Of kijk gewoon naar whoami z'n post Moet ff wat sneller leren typen

---

Mijn Advies:
Zo als je al zegt heb je weinig webprogrammeer ervaring, nu weet ik niet wat voor andere programmeer ervaring je zou hebben maar als deze 0,0 is adviseer ik je PHP / MySQL. Hier is heel veel documentatie over te vinden en vrij makkelijk te leren. Zo hoef je geen rekening te houden met typen van variabelen en is het zoals je zei ook gratis te gebruiken. Een PHP code werkend krijgen is stap 1 hierbij en het koppelen aan databases een 2e stap. Een PHP code echter optimaliseren is dan iets waar je je later over kan buigen, zo valt het gebruik van bepaalde functies flink tegen op performance (minimaal vaak maar toch) wat voor een applicatie veel kan schelen.

[ Voor 53% gewijzigd door Glock op 22-01-2003 15:50 ]

[ACM]

Vergeet dan JSP/Servlets, CF, (fast)cgi, (mod_)perl en dergelijke niet

Een stel andere gratis databases zijn nog firebird van www.ibphoenix.org en sapdb www.sapdb.org

Maar inderdaad, simpelweg "use the right tool for the job" is het devies. En afhankelijk van je voorkeuren en de eisen die je omgeving stelt zijn er verschillende adviezen te geven.

Dit als aanvulling op whoami, nu even kijken of ik nog een persoonlijk advies kan geven

[Pooh]

Verwijderd schreef op 22 January 2003 @ 15:33:
Mijn vraag is dus: welke 'programmeertaal' is hiervoor nodig en/of wordt door jullie aanbevolen? Ik heb zelf een lichte voorkeur voor PHP/MySQL, gezien het feit dat dit kostentechnisch een prima oplossing lijkt. Echter, kun je er bij PHP voor zorgen dat automatisch een e-mailtje wordt verstuurd wanneer er informatie aan de 'productinformatie-database' wordt toegevoegd, gebaseerd op de selectie van de klant?

Ruwweg zijn er 2 mainstream opties: php/mysql of asp(.net?)/access(mssql). Kostentechnisch lijkt php misschien gunstiger, maar dat hangt van nogal wat factoren af. De ervaring van de developer is het belangrijkste: als je een goede ASP programmeur kunt vinden, moet je hem niet opdragen in PHP bezig te gaan, omdat manuren meestal duurder zijn dan software. Bovendien (maar dat is mijn perceptie) heb ik 't idee dat asp vaak net iets kortere ontwikkeltijden oplevert. Aan de andere kant zijn er denk ik weer meer hobbyisten die php kunnen...

Een interessante discussie hierover: PHP / ASP dillemma - overtuig mijn klant!

acm:Vergeet dan JSP/Servlets, CF, (fast)cgi, (mod_)perl en dergelijke niet

Tsja... dan word 't denk ik moeilijk om goedkope ervaren hobbyisten of semi-professionals te vinden...

[ Voor 12% gewijzigd door Pooh op 22-01-2003 15:47 ]

[Bobco]

Mja, welke spullen heb je al? Het belangrijkste is dat het eindresultaat doet wat jij wilt. Als je belangrijkste criterium de aanschafprijs is dan zijn open source produkten de aangewezen weg om in te slaan. Ik neem aan dat je wel weet waar je de applicatie gaat hosten?

De functionaliteit die je noemt is niet schokkend en kan in een willekeurige programmeertaal in elkaar geschroefd worden. Iets waar je wel even bij stil moet staan is de toekomstige onderhoudbaarheid. Gaat er nog iets wijzigen aan de applicatie? Verwacht je een sterke groei in het aantal gebruikers?

Als je hierboven al de volledige functionaliteit van de applicatie hebt beschreven dan is dit voor iemand met een beeje ervaring in minder dan een week in elkaar te zetten.

[ACM]

Als we er van uit gaan dat het developpen even duur en evenveel tijd kost (of minder tijd, maar duurder per uur of meer tijd, maar goedkoper per uur) voor de verschillende platformen blijft het technische plaatje over.

php en mysql vormen een redelijk aardig combo, door een lichte "afkeer" van mysql zou ik het een "zilveren koppel" noemen. Mijn persoonlijke voorkeur voor databases ligt bij postgresql en dat werkt zeker net zo goed samen met php als mysql. Php/postgresql op een unix platform met apache heeft daardoor mijn persoonlijke voorkeur. En dat is in mijn ogen dus een zeer geschikt platform voor vrijwel alle ontwikkelingen.

Servlets en jsp zijn lichtelijk superieur aan php, in mijn visie en er zijn ook goede en goedkope (jboss, tomcat zijn zelfs gratis) servletengines voor.
Nadeel is dat je java moet toepassen wat nog wel een hogere drempel heeft en daardoor duurder per uur kan zijn om te ontwikkelen.

De dingen die ik over php zeg kan je, heel ruwweg, ook over asp zeggen en dat wat ik over java zeg heel ruwweg ook over ASP.NET...

Mijn persoonlijke advies wordt dan:
Gebruik php met postgresql als je wat complexere logica in je database wilt toepassen en het echt betrouwbaar moet zijn.
Gebruik php met mysql als je vooral hele simpele queries doet (selects van enkele tabellen met hele simpele where's) en dat op je scherm wil gooien.

Ik heb zelf dus de voorkeur voor de eerste helft van mijn advies, simpelweg omdat postgresql echt sneller is dan mysql zodra de boel complexer wordt en bij de simpelere queries is het verschil ook niet gigantisch

Met als kleine aanvulling, mocht je het gelijk goed willen doen. Neem dan servlet/jsp met postgresql, dat schaalt net weer wat beter dan php en met servlet-side cacheing kan je alle nadelen van postgresql vs mysql royaal opvangen

[Verwijderd]

Wow... dat zijn er meer (reacties) dan ik had verwacht!

Natuurlijk wil ik niet dat mijn verzoek leidt tot een over en weer van "A is de beste" en "nee, B is beter", enzovoorts. Mijn voorkeur voor PHP is voor een groot deel te verklaren uit het feit dat een hoop mensen hier hobbymatig mee bezig zijn, en financieel kan ik hier misschien mijn voordeel mee doen door relatief goedkoop bepaalde dingen uit te laten voeren. Echter, ik hoef ook weer niet voor een dubbeltje op de eerste rang te zitten, en als blijkt dat het toch moeilijker is dan gedacht, laat ik het wel door een professional doen. Ik dacht gewoon dat als er een ontwikkeltaal (?) is die voor dit soort projecten bij uitstek geschikt is (of misschien juist wel ontwikkeld is), deze hier wel zou worden genoemd. Maar misschien zat ik wel gewoon onbewust te wachten op een "Ja, dit kan met PHP/MySQL".

Gezien de reacties, zal ik voorlopig mijn onderzoek richten op de mogelijkheden van PHP/MySQL. Bedankt voor de snelle reacties. Mocht het niet lukken, weet ik jullie te vinden.

/edit

Maak daar PHP/MySQL en PHP/postgresql van.

Aanvulling: Ik heb de situatie zo uitgebreid mogelijk geschetst. Bedrijf A voert de productinformatie in, en geeft aan onder welke productcategorie het product valt. Klant A geeft aan in welke (soort) producten hij is geinteresseerd, en telkens als er door een bedrijf informatie en/of producten wordt toegevoegd, ontvangt de klant hierover informatie. Dus de info die door een bedrijf wordt ingevoerd, wordt via e-mail naar de klant verzonden. That's it, really. Waar het vooral om gaat is dat dit allemaal zonder 'handmatige tussenkomst' van de tussenpersoon te regelen is. Deze moet bijvoorbeeld niet de e-mailtjes handmatig gaan opmaken en versturen, want dat zou teveel geld kosten. Tevens moeten de e-mail adressen van klanten niet bij de overige klanten bekend worden gemaakt, dus beveiliging is ook van groot belang.

Wat betreft welke spullen ik al heb: nog helemaal niets. Het is maar een idee waar ik al een tijdje op zit te broeden, en of het allemaal uiteindelijk ook zal worden uitgevoerd hangt natuurlijk ook van de totale kosten af en of er misschien geld kan worden terugverdiend. De keuze op welke hardware alles komt te draaien en welke software dient te worden aangeschaft, wordt later besloten.

Last but not least: Ik ben niet van plan zelf te programmeren. Dit wordt, zoals gezegd, allemaal uitbesteed. Dus dat de ene taal makkelijker is dan de andere is niet echt van belang. Wat wel van belang is, is welke taal het beste geschikt is voor de taak. Of ik nu iemand moet inhuren die alles van PHP kent, of alles van ASP kent maakt vrij weinig uit voor de situatie (behalve financieel dan misschien).

[ Voor 49% gewijzigd door Verwijderd op 22-01-2003 16:18 ]

[The-Source]

Ik ben laatst bezig geweest met een webshop maken voor een school project en hierbij moesten wij ook een begroting maken.
Wij kozen direcht voor MySQL omdat deze zeer snel en ook nog eens gratis is.
Wij konden zelf kiezen wat we als server software gingen draaien zolang de opdrachtgever dit goedkeurde.
Nu kwam het probleem dat er alleen programmeer kennis was in asp in ons groepje dus bij ons vielen de rest van de programmeer talen af.
Nu is MySQL niet zo makkelijk aan te spreken in asp dan in php maar als je MyODBC van de mysql site download gaat dit in eens een heel stuk makkelijker (alleen windows machines).
PHP is heel makkelijk onder windows te installeren dus php is meer onafhankelijk dan asp omdat deze geen goede freeware versie heeft voor linux.

Conclusie (in mijn bewoording ): Als je je site in ASP i.c.m. MySQL database laat maken dan ben je bijna afhankelijk van een Windows OS.
Als je site in php i.c.m. MySQL database laat programmeren ben je meer platform onafhankelijk.
En er zijn zat mensen in je buurt te vinden die minstens 1 van beide talen kunnen en als je een beetje rond vraagt hoort dit ook makkelijk voor een zacht prijsje te kunnen.

[djluc]

Wat je wilt is niet moeilijk, het is echt een basissysteempje zou je wel kunnen zeggen. Natuurlijk kun je dit steeds uitbreiden Wat me eigenlijk vooral opvalt is dat we het nog weinig hebben over aantallen bezoekers en producten. Ook heb je het over hardware gehad, ga je het zelf hosten?

Als je het over vele duizenden bezoekers per dag hebt die heel jouw shop gaan doorzoeken en honderden mailtjes per dag gaat versturen, dan wordt het niet meer echt te behappen voor mysql, Postgre was volgens mij al wel wat beter hiervoor.

Een e-mailfunctie is in elke taal mogelijk, daar hangt het dus niet vanaf.

Als je echt een professioneel bedrijfje/shopje wilt gaan beginnen is het aan te raden om of een vaste programmeur te nemen. En dan dus wel iemand die ook echt begrijpt waar het om gaat, dus niet meteen het zoontje van de buren oid. Of je neemt een professioneel bedrijf in de arm, dan ben je wel wat meer kwijt maar je hebt dan wel iemand die de verantwoording kan dragen, en als er storing oid is verantwoordelijk gesteld kan worden. Dat is toch moeilijk bij een of andere wizzkid, uiteindelijk zijn jouw inkomsten toch grotendeels afhankelijk van zijn werk.

[chris]

ik zou dus toch echt voor php/mysql kiezen. Dit is verreweg de populairste taal, en hierin zul je ook het makkelijkst een goedkope programmeur kunnen vinden. Je kan wel PostgreSQL kiezen, maar dit is veel duurder en er zullen vooral ervaren programmeurs zijn die hier verstand van hebben.

offtopic:
waarom zet je je e-mail adres niet in je profile? Ik denk dat er hier genoeg programmeurs rondlopen die wel interesse hebben...

[ACM]

/dev/null schreef op 22 January 2003 @ 16:54:
Je kan wel PostgreSQL kiezen, maar dit is veel duurder en er zullen vooral ervaren programmeurs zijn die hier verstand van hebben.

Die vat ik niet
Waarom zou het duurder zijn?

en dat gewauwel over ervaren zijn voor je postgres kan gebruiken.. Als je sql kan, kan je dat beter in postgresql dan in mysql, want mysql houdt zich veel minder goed aan de standaard. (kortom, iedereen met een beetje sql ervaring zal dat net zo goed in postgresql als in mysql kunnen uitten)
Beheerstechnisch moet je misschien iets meer doen voor postgresql, maar het is zeker niet moeilijker ofzo.

[ Voor 42% gewijzigd door ACM op 22-01-2003 16:59 ]

[mbravenboer]

Als je hier advies vraagt voor serieuze zaken die kritiek kunnen zijn voor een bedrijf, moet je wel goed beseffen aan wie je advies vraagt. Je kan als je hier niet langere tijd rond hebt gehangen slecht inschatten hoe waardevol een advies is wat hier gegeven wordt. Misschien valt een bepaalde post je wel helemaal niet op, terwijl er toch iemand achter zit met fundamenteel meer inzicht en ervaring. Er lopen hier met name studenten of zelfs niet opgeleide hobby-programmeurs rond. Op zich prima om daar advies aan te vragen, zolang je maar wel beseft wat je doet!

Vanaf de andere kant gezien moet je je als adviesgever misschien af en toe ook eens realiseren hoe serieus je advies wel niet genomen kan worden en of je dan inderdaad wel advies zou moeten geven ...

[Verwijderd]

Tja, het probleem is dat ik (nog) niet in detail kan uitleggen waar het om gaat. Het is echter wel zo dat men de site alleen maar hoeft te bezoeken om productgegevens in te voeren (alleen bedrijf), om zich aan of af te melden (zowel bedrijf als klant), of om de voorkeuren bij te werken (klant). Het gaat voornamelijk om het hele e-mail gebeuren die, gekoppeld aan de database van gebruikers en productgegevens, goed en veilig moet worden opgebouwd.

Wat betreft de hardware zal ik waarschijnlijk om te beginnen een vrij 'standaard' hostingpakket nemen bij een van de bekendere hostingproviders. Zo heb ik bijvoorbeeld even bij mijn eigen provider gekeken (XS4ALL), en die bieden bijvoorbeeld een shared hosting Unix-pakket aan voor e.104,50 per maand, die PHP4 en MySQL ondersteunt met zo'n 200MB schijfruimte en 10GB dataverkeer. Volgens mij zou dat voorlopig wel genoeg moeten zijn, toch? Later kan ik als dit nodig mocht zijn altijd nog kunnen upgraden naar een wat uitgebreider pakket. Ik verwacht geen stormloop op de website, dus de hoeveelheid traffic zal wel meevallen. Alleen zullen er in het meest optimale geval enkele duizenden e-mails per dag moeten worden verstuurd, en afhankelijk van de mogelijkheden van het systeem en de wensen van de klanten kunnen deze ook foto's bevatten van de producten... hmm.

Zelf hosten...? Tja, heb ik ook wel even aan zitten denken, maar ik heb daar eigenlijk veel te weinig tijd voor. Dan zou ik eerst moeten uitvogelen wat voor soort hardware ik nodig heb en wat voor abonnement ik dan zou moeten nemen, maar daar is dit gedeelte van het forum niet voor bedoeld.

/dev/null: Your wish is my command.

mbravenboer: Ik begrijp wat je bedoelt te zeggen, maar wat ik in gedachten heb is niet voor een bedrijf. Ik wil gewoon proberen een dienst op te zetten die voor bedrijven en particulieren bedoeld is, en het zou leuk zijn zij daar ook gebruik van zouden maken. Ik moet het allemaal zelf bekostigen, en er is geen bedrijf dat mij gevraagd heeft dit op te zetten. Ik ben zelf ook maar een hobbyist, dus alle hulp van andere hobbyisten is meer dan welkom. Het is geen project dat per se moet slagen, het is gewoon een beetje aanrommelen. Onder het motto: Nothing ventured, nothing gained.

[ Voor 17% gewijzigd door Verwijderd op 22-01-2003 17:21 ]

[ACM]

Voor vele mails per dag moet je je hoster wel even informeren denk ik, stellen ze wel op prijs en wellicht dat ze dan voor je de boel anders configureren (negeren van bounce-mails bijv) en/of beter kunnen plaatsen op een van hun servers.

Xs4all staat iig als een goed hoster bekend en voor dat bedrag mag je wel wat extra 'support' verwachten imho, wellicht zelfs het installeren van postgresql

Je doet er iig vrij lang over om 200MB aan schijfruimte te vullen, maar probeer de mail-verstuur-scripting wel efficient te laten houden, want enkele duizenden mailtjes per dag is per stuk (afhankelijk van de scripting) soms wel 5Kb of meer per stuk
Of ze dat ook mee kunnen rekenen in hun traffic statistieken is wat anders, het is vrij lastig te doen, maar kan wel.

[djluc]

Je hebt het nu over duizenden mailtjes per dag, wat ik me dan even af aan het vragen was, hoeveel klanten verwacht je en hoevaak krijgen zij een mailtje?

[Gwaihir]

xxSQL is in mijn visie toch wel heel erg SQL: qua programmeer-moelijkheid onderling redelijk vergelijkbaar. Vaak is ook een abstraction layer aan te raden (stukje programma wat de onderlinge verschillen tusssen de database systemen verbergt voor de rest van het systeem.) MySQL mag dan wel de bekendheid hebben, dat wil zeker niet zeggen dat PostgreSQL niet beter of handiger kan zijn. (Zelf ben ik al tegen verschillende MySQL beperkingen aangelopen; doch met Postgre heb ik niet echt ervaring, dus ik ga daar geen oordeel over vellen.)

Waar het om hosting gaat is Unix/PHP veruit het makkelijkst en goedkoopst te vinden, meestal samen met MySQL, maar soms ook met Postgre, kwestie van even zoeken. Windows/ASP is eigenlijk altijd duurder.

Dat even zoeken zou ik sowieso aanraden: mijn hostingpakket heeft dezelfde specs als jij noemt, maar kost 9,95 per maand (Jaguarpc.net). Nog goedkoper kan ook, maar het wordt dan wel steeds moeilijker om een betrouwbare host te vinden - je site moet tenslotte wel echt 'up' zijn en dat is lastig tevoren in te schatten, anders dan 'te goedkoop om waar te zijn' is meestal ook niet waar. Wanneer je inderdaad tot een 'wiz-kid built' systeem komt dan lijkt me zo'n voordelige hosting zeer bijpassend: de door djluc geschetste issues zullen al snel meer problemen geven dan je host.

Bij de meeste hosts telt e-mail overigens wel mee bij traffic (en anders kan dat volgende week veranderen - het wordt nl. met software steeds makkelijker gemaakt voor die hosts om alles mee te tellen). 10GB is dan geen pure luxe, maar lijkt me wel voldoende.

Bij die hoeveelheid uitgaande mail zou ik wel je host zeer goed informeren over wat je aan het doen bent. Een paar SPAM klachten heb je zo te pakken (ook al zijn ze onterecht) en je wilt niet onverwacht afgesloten worden.

> Ben wel nieuwsgierig wat Glock over 'liever mijden' PHP functies kan zeggen. Linkje? <

[Glock]

Birdie schreef op 22 januari 2003 @ 17:50:
> Ben wel nieuwsgierig wat Glock over 'liever mijden' PHP functies kan zeggen. Linkje? <

Hier valt niet zo heel veel over te zeggen, eerder persoonlijke ervaringen. Een linkie heb ik dus helaas niet maar wanneer je op een pentium 133 met 32 mb php scripts laat runnen merk je tussen bepaalde functies wel degelijk flinke tijdverschillen.

• Zo is mij opgevallen dat bijvoorbeeld bij templates een str_replace sneller kan (en in 9 uit de 10 gevallen dit ook is) zijn als dat je php variabelen zou gebruiken.
• Er zit een zeer groot tijdsverschil tussen functies als mysql_fetch_array en mysql_fetch_assoc (vrij bekend geloof ik)
• Een (MySQL) Query in je script op meerdere lijnen laten staan levert performance verlies op. (Weet niet of dit nou precies aan php of mysql ligt)

Zo meer kan ik me op dit moment niet bedenken maar dit ligt vooral aan wat de PHP coders aan functies geoptimaliseerd hebben. Zo is mysql_fecht_array($var, MYSQL_ASSOC) sneller als mysql_fetch_assoc terwijl ze toch beide echt hetzelfde doen.

edit:
Ik kan me voorstellen dat je het op mega bakken niet voor die milli seconden doet maar vaak is het wel de moeite waard om het na te kijken.

[ Voor 8% gewijzigd door Glock op 22-01-2003 18:35 ]

[whoami]

Glock schreef op 22 januari 2003 @ 18:32:
[...]

Hier valt niet zo heel veel over te zeggen, eerder persoonlijke ervaringen. Een linkie heb ik dus helaas niet maar wanneer je op een pentium 133 met 32 mb php scripts laat runnen merk je tussen bepaalde functies wel degelijk flinke tijdverschillen.
[list]
• Zo is mij opgevallen dat bijvoorbeeld bij templates een str_replace sneller kan (en in 9 uit de 10 gevallen dit ook is) zijn als dat je php variabelen zou gebruiken.
• Er zit een zeer groot tijdsverschil tussen functies als mysql_fetch_array en mysql_fetch_assoc (vrij bekend geloof ik)
Zo meer kan ik me op dit moment niet bedenken maar dit ligt vooral aan wat de PHP coders aan functies geoptimaliseerd hebben. Zo is mysql_fecht_array($var, MYSQL_ASSOC) sneller als mysql_fetch_assoc terwijl ze toch beide echt hetzelfde doen.

Performance issues zijn wel belangrijk, maar wat ik nog veel belangrijker vind, is dat een databank in staat moet zijn om de integriteit van de gegevens te waarborgen. Voor zover ik weet, is het nog steeds niet mogelijk om in MySQL referentiele integriteit af te dwingen, dus voor mij zo MySQL als DBMS al afvallen.
Verder zijn er nog een aantal features die ontbreken in MySQL zoals subqueries.
(Alhoewel er wel aan die zaken gewerkt wordt.)

• Een (MySQL) Query in je script op meerdere lijnen laten staan levert performance verlies op. (Weet niet of dit nou precies aan php of mysql ligt)
[/list]

Dit zal wel aan PHP liggen. De query zal pas naar de DB gestuurd worden als die door PHP volledig opgebouwd is. De databank heeft dus niet te maken met die verschillende strings en ziet dat sql statement net alsof je het op één lijn zou zetten.
Het concateneren van een string is meestal traag vanwege het feit dat een string immutable is.

[ProgrammerX]

Het enige dat ik hier even wil melden is dat jouw systeem staat of valt met invoeren van de informatie door de bedrijven. Ik bedoel dat als je ze te vrij laat bij het invoeren, dan komt hun informatie verkeerd terecht in jouw systeem en dus ook bij de verkeerde klanten. Je hele systeem draait op het correct aanbieden van informatie aan je klanten, dus probeer de bedrijven goed te begeleiden bij de invoer. Misschien een open deur, maar ik wou het toch even melden

Let tevens goed op de security van het hosting bedrijf. Ben je er niet helemaal zeker van, zoek dan liever iemand anders. Dit zeker gezien de privacy van je klanten en voornamelijk de grote hoeveelheid email die je gaat versturen (tegenwoordig zit er snel een virus in een mail). Persoonlijk vind ik xs4all misschien iets duur, maar ze zijn wel super in kwaliteit en service.

En het advies dat hier gegeven wordt is over het algemeen wel van goede kwaliteit hoor (hier zitten ook veel beroepsmatige ict'ers), maar het blijft toch altijd nodig om je door meerdere mensen te laten informeren en je eigen onderzoek te doen

Veel succes verder

[Verwijderd]

djluc schreef op 22 januari 2003 @ 17:43:
Je hebt het nu over duizenden mailtjes per dag, wat ik me dan even af aan het vragen was, hoeveel klanten verwacht je en hoevaak krijgen zij een mailtje?

Duizenden mailtjes is een zeer ruime schatting, en dit zal alleen het geval zijn als er honderden particulieren deelnemen (zo hard zal het hoogstwaarschijnlijk niet lopen, zeker niet voor het systeem compleet op poten is gezet). Mocht het echter wel zo ver komen, dan is het altijd mogelijk om t.z.t. op 'zwaarder geschut' over te stappen en een uitgebreider hostingpakket te kiezen. Daarbij komt tevens dat deze mailtjes slechts eens in de 7 - 14 dagen verstuurd gaan worden. Zo'n twee tot vier keer per maand gaan die mailtjes dus de deur uit, en niet dag in dag uit.

[ Voor 3% gewijzigd door Verwijderd op 22-01-2003 21:33 ]

[Glock]

whoami schreef op 22 januari 2003 @ 18:36:

Performance issues zijn wel belangrijk, maar wat ik nog veel belangrijker vind, is dat een databank in staat moet zijn om de integriteit van de gegevens te waarborgen. Voor zover ik weet, is het nog steeds niet mogelijk om in MySQL referentiele integriteit af te dwingen, dus voor mij zo MySQL als DBMS al afvallen.
Verder zijn er nog een aantal features die ontbreken in MySQL zoals subqueries.
(Alhoewel er wel aan die zaken gewerkt wordt.)

DBMS is iets waar MySQL idd voorlopig nog niet zal toebehoren, althans versie 3. Meer intregiteit samen met oa subqueries is word dit allemaal al goed ingebouwd in versie 4, deze mag dan nog wel beta zijn maar rijkt al veel verder (en valt in mijn ogen als stable te beschouwen) als versie 3. En is de waarborging die jij noemt niet al meerendeels te verkrijgen bij InnoDB? En mocht je sub selects enzovoorts nodig hebben, waardoor het duidelijk is dat je toch wat uitgebreidere queries wil dat je een database kiest welke hierbij past, in dit geval dus ProsteSQL ja. Maar ik vind dat een overbodige luxe tegenover de performance, iets wat met subselects valt af te handelen kan je ook zonder. Zonder de effectifiteit van je opzet te verliezen.

Dit zal wel aan PHP liggen. De query zal pas naar de DB gestuurd worden als die door PHP volledig opgebouwd is. De databank heeft dus niet te maken met die verschillende strings en ziet dat sql statement net alsof je het op één lijn zou zetten.
Het concateneren van een string is meestal traag vanwege het feit dat een string immutable is.

no comment

[ACM]

Glock schreef op 22 januari 2003 @ 23:26:
DBMS is iets waar MySQL idd voorlopig nog niet zal toebehoren, althans versie 3. Meer intregiteit samen met oa subqueries is word dit allemaal al goed ingebouwd in versie 4, deze mag dan nog wel beta zijn maar rijkt al veel verder (en valt in mijn ogen als stable te beschouwen) als versie 3.

Je noemt hier 4.x stable, toch is 4.0 al meer dan een jaar in alpha/beta/gamma ontwikkeling sinds de aankondiging eind 2001.
Lijkt me dat er toch een reden is dat het er nog niet is en vergeet niet dat van een dbms wordt verwacht dat het 'stable' is, maar dat het rockstable is...
Alle noemenswaardige concurrenten komen mij stabieler over dan mysql, ook al zijn een groot deel van de concurrenten duur(der) in gebruik.

De boodschap hiervan: Als mysql 4.0 production stable was had mysql AB dat wel production stable verklaart.

En is de waarborging die jij noemt niet al meerendeels te verkrijgen bij InnoDB?

InnoDB werkt aardig, maar kan nog niet tippen aan de concurrentie imho. Alleen op het gebied van performance met erg simpele queries.

En mocht je sub selects enzovoorts nodig hebben, waardoor het duidelijk is dat je toch wat uitgebreidere queries wil dat je een database kiest welke hierbij past, in dit geval dus ProsteSQLPostgreSQL ja. Maar ik vind dat een overbodige luxe tegenover de performance,

De luxe van een rockstable dbms dat wel garanties over je referentiele integriteit kan geven en nog een aantal andere zaken ondersteund (zoals subqueries, procedures, triggers, e.a.) tov een beetje performance verlies op simpele queries en performance winst bij de complexere queries, dat vind je dus niet goed?

iets wat met subselects valt af te handelen kan je ook zonder. Zonder de effectifiteit van je opzet te verliezen.

Het verplicht om de subselects heen te werken door query-code in je applicatie te stoppen is eigenlijk gewoon onzin en erg slecht, zeker voor je performance en indien van toepassing je integriteit en de atomairiteit.
En soms kan je het met gewone, niet subselected, queries oplossen, maar zeker niet altijd.


Nahja, mijn mening is lichtelijk gekleurd door meerdere tegenvallers en grotere problemen met mysql, terwijl ik dat soort dingen nooit of veel minder erg in postgresql heb meegemaakt...

[Glock]

ACM schreef op 22 January 2003 @ 23:53:
De boodschap hiervan: Als mysql 4.0 production stable was had mysql AB dat wel production stable verklaart.

Voor zover ik weet is dit toch nog zo omdat het niet uitgebreid getest is, ik loop mysql 4 al sinds het begin te gebruiken zonder ooit enige problemen tegen te komen.

De luxe van een rockstable dbms dat wel garanties over je referentiele integriteit kan geven en nog een aantal andere zaken ondersteund (zoals subqueries, procedures, triggers, e.a.) tov een beetje performance verlies op simpele queries en performance winst bij de complexere queries, dat vind je dus niet goed?

Het verplicht om de subselects heen te werken door query-code in je applicatie te stoppen is eigenlijk gewoon onzin en erg slecht, zeker voor je performance en indien van toepassing je integriteit en de atomairiteit.
En soms kan je het met gewone, niet subselected, queries oplossen, maar zeker niet altijd.

Dit vind ik perfect, en ben ik me ook prima van bewust. Probeerde alleen aan te duiden dat in 3 uit de 5 gevallen de complexere queries niet _nodig_ zijn. Ik zie vaak genoeg mensen uitgebreide en complexe queries maken en daarbij bv ook PostgreSQL (ja, deze keer goed gespeld ) gebruiken terwijl dit veel efficienter valt op te lossen. Dit doen ze _meestal_ omdat ze vaak gehoord hebben dat complexere queries 'beter' zijn. Een extra nadruk op dit feit kan nooit kwijt omdat dit gewoon iets is waar je goed over moet nadenken voordat je iets gaat programmeren.

Nahja, mijn mening is lichtelijk gekleurd door meerdere tegenvallers en grotere problemen met mysql, terwijl ik dat soort dingen nooit of veel minder erg in postgresql heb meegemaakt...

En ik praat dus weer de goede ervaringen die ik met MySQL heb meegemaakt en vind daarnaast postgresql dus ook een prima product. Deze hele discussie begint volgens mij dus weer meer te neigen naar wat in het begin al is gezegd:
"Use the right tool for the right job."

edit:
Iets verbeteren en dan de aanvulling verkeerd spellen

[ Voor 6% gewijzigd door Glock op 23-01-2003 11:22 ]

[Verwijderd]

Ik denk dat de programmeertaal in deze zeer weinig uit maakt. Waar het voornamelijk om gaat is:
1) kosten: hoeveel kost het eenmalig om de software te laten ontwikkelen, en wat zijn de periodieke kosten voor hosting
2) expertise: je kan beter iets meer betalen voor een expert dan minder voor een knutselaar. Programmeren is nog steeds een ambacht, en als jij op basis van deze software je brood moet verdienen, moet het kwaliteit zijn.
3) continueiteit: Het is van belang dat wijzigingen in jouw business behoeften snel doorgewerkt kunnen worden in jouw software, en dat problemen snel opgelost kunnen worden.

Mijn advies op basis hiervan: het belangrijkste is welke developer(s) je gaat inhuren. Zolang zij voldoende ervaren zijn in 1 bepaalde ontwikkelomgeving maakt het voor jou niets uit wat die omgeving is, zolang het maar redelijk goedkoop gehost kan worden.

HTH

[ACM]

Glock schreef op 23 januari 2003 @ 09:52:
Dit vind ik perfect, en ben ik me ook prima van bewust. Probeerde alleen aan te duiden dat in 3 uit de 5 gevallen de complexere queries niet _nodig_ zijn.

Zie bijv ook dit:

code:

ripe=# SELECT ipfrom, ipto, country  FROM ip_country 
   WHERE '145.94.00.00'  BETWEEN ipfrom AND ipto;
   ipfrom   |      ipto      | country
------------+----------------+---------
 145.0.0.0  | 145.128.0.0    | NL
 145.91.0.0 | 145.94.255.255 | NL
(2 rows)

Time: 105.18 ms

MySQL:

mysql> SELECT inet_ntoa(ipfrom), inet_ntoa(ipto), country  FROM ip_country 
   WHERE inet_aton(  '145.94.00.00'  )  BETWEEN ipfrom AND ipto;
+-------------------+-----------------+---------+
| inet_ntoa(ipfrom) | inet_ntoa(ipto) | country |
+-------------------+-----------------+---------+
| 145.0.0.0         | 145.128.0.0     | NL      |
| 145.91.0.0        | 145.94.255.255  | NL      |
+-------------------+-----------------+---------+
2 rows in set (0.22 sec)

2x zo snel op postgresql, en zo complex is de query niet eens... Mysql mag een integer-vergelijking (op een index) direct bij de query en postgresql moet zijn interne "ip-formaat" toepassen (wat zelfs een long/bigint is of iig op een andere manier geen integer, want het kan er ook de netmask bij opslaan).
Kortom, lijkt me een eerlijke vergelijking van een simpele query...
(het is heus niet altijd zo dat zulk soort queries sneller op postgresql zijn hoor )

Een andere query die ik bijvoorbeeld voor de enquete-tool die ik voor tweakers.net gemaakt heb gebruik is zoiets:

code:

acm=# SELECT answers.answertext,
acm-# answers.answerid,
acm-# count(answered_question.answerid) AS answercount
acm-# FROM
acm-# answers
acm-# NATURAL LEFT JOIN answered_question
acm-# WHERE
acm-# answers.questionid = '30'
acm-# GROUP BY answers.answerid, answers.answertext, answers.answerorder
acm-# ORDER BY answers.answerorder;
         answertext         | answerid | answercount
----------------------------+----------+-------------
 In Nederland.              |       73 |        1007
 In België.                 |       78 |          23
 In een ander land.         |       83 |           9
 Dat gaat jullie niets aan. |       87 |           9
(4 rows)

Time: 22.81 ms

MySQL:

mysql> SELECT answers.answertext,
    -> answers.answerid,
    -> count(answered_question.answerid) AS answercount
    -> FROM
    -> answers
    -> NATURAL LEFT JOIN answered_question
    -> WHERE
    -> answers.questionid = '30'
    -> GROUP BY answers.answerid, answers.answertext, answers.answerorder
    -> ORDER BY answers.answerorder;
+----------------------------+----------+-------------+
| answertext                 | answerid | answercount |
+----------------------------+----------+-------------+
| In Nederland.              |       73 |        1007 |
| In België.                 |       78 |          23 |
| In een ander land.         |       83 |           9 |
| Dat gaat jullie niets aan. |       87 |           9 |
+----------------------------+----------+-------------+
4 rows in set (0.06 sec)

3x zo snel in postgresql...
Toch een type query dat redelijk vaak gebruikt zal worden... En al enigszins complex is.

Ik zie vaak genoeg mensen uitgebreide en complexe queries maken en daarbij bv ook PostgreSQL (ja, deze keer goed gespeld ) gebruiken terwijl dit veel efficienter valt op te lossen. Dit doen ze _meestal_ omdat ze vaak gehoord hebben dat complexere queries 'beter' zijn. Een extra nadruk op dit feit kan nooit kwijt omdat dit gewoon iets is waar je goed over moet nadenken voordat je iets gaat programmeren.

Dat ben ik met je eens, als je iets met een eenvoudige query kan oplossen moet je het niet in een complexe stoppen, maar als je ertoe gedwongen bent een "complexe" query toe te passen, dan verliest mysql het snel...

En ik praat dus weer de goede ervaringen die ik met MySQL heb meegemaakt en vind daarnaast postgresql dus ook een prima product. Deze hele discussie begint volgens mij dus weer meer te neigen naar wat in het begin al is gezegd:
"Use the right tool for the right job."

En dat laatste statement blijft gewoon altijd waar

[djluc]

Dat is idd een van de belangrijkste dingen, alleen gaat het er dan wel om: laat de juiste mensen de juiste tool gebruiken om het doel te bereiken

Duizenden mailtjes is een zeer ruime schatting, en dit zal alleen het geval zijn als er honderden particulieren deelnemen

Hoeveel mailtjes per persoon ga je versturen?

[Verwijderd]

Verwijderd schreef op 22 januari 2003 @ 16:02:
Wow... dat zijn er meer (reacties) dan ik had verwacht!

Natuurlijk wil ik niet dat mijn verzoek leidt tot een over en weer van "A is de beste" en "nee, B is beter", enzovoorts. Mijn voorkeur voor PHP is voor een groot deel te verklaren uit het feit dat een hoop mensen hier hobbymatig mee bezig zijn

nou ... er zijn best genoeg bedrijven die ook gewoon php gebruiken. Tis maar wat je zelf lekker vind programmeren. Zelf had ik ASP ook geprobeerd en ook PHP. Uiteindelijk vond ik php toch lekkerder werken ... was ook snel geinstalleerd bij mij dus testen ging snel. Probeer ze allebei eens je kan bijvoorbeeld een case maken voor beide talen, voorbeeld ... maak een klein website in ASP en PHP di hetzelfde moet doen ( voorbeeld inloggen,een waarde wegschrijven naar een DB en waar ophalen) en kijk wat het lekkerste programmeerde ( denk ook aan de tools enzo die je moet installeren of webserver etc ).

Veel succes ...