[PHP]include .php file of .txt uitlezen? Performance?,Flexi

[Verwijderd]

heb een algemene vraag over PHP in verband met performance, maintenance en flexibiliteit

ik wil de content van mijn site gaan vullen en wil het op een van de volgende manieren doen:

1. content uit een .txt file lezen (met fopen oid en output-en, dit is op het moment mijn keuze, tenzij jullie anders kunnen beweren)
2. content uit een .php file includen (=ben ik ook niet echt voor)
3. content uit een database lezen (==ben ik niet voor)
4.hardcore in de code typen (==ben ik zelf niet voor)

ik zou graag meningen en argumenten van jullie willen horen welke methode jullie gebruiken.

[ixi]

Hangt heel erg af wat voor soort page je hebt. Die 4 methodes kan je zo moeilijk met elkaar vergelijken. Voor meer statische gegevens kun je het beste 1 (of 2) gebruiken, wil je echter wat leukere dingen gaan doen ontkom je volgens mij niet aan een database. Methode 4 valt voor mij sowieso af, veel te lastig met onderhoud.

Qua performance maakt het allemaal niet zo gek veel uit. Methode 4 is het snelst, daarna 1 & 2, en dan 3 (afhankelijk van wat je wilt natuurlijk).

Wat wil je precies gaan maken?

[-GSF-JohnDoe]

het grote voordeel van een database is dat het heel flexibel is, terwijl je het meeste werk (selecties, sorteren) door SQL kan laten doen. En SQL is daar juist voor gemaakt dus dat is wel efficient.

Persoonlijk is een MySQL dbase met php voor een dynamische website voor mij favoriet.

en tenzij het een ontzettend zware website is maakt die efficientie niet onwijs veel uit.

[ Voor 14% gewijzigd door -GSF-JohnDoe op 30-11-2003 03:52 ]

[Brakkie]

Vertel er anders even bij om wat voor soort site het gaat. Als de informatie vaak gewijzigd gaat worden is het het makkelijkst werken met een database. Er is in een database makkelijker structuur aan te brengen dan in een systeem met text files.

[Verwijderd]

Brakkie schreef op 30 november 2003 @ 06:00:
Vertel er anders even bij om wat voor soort site het gaat. Als de informatie vaak gewijzigd gaat worden is het het makkelijkst werken met een database. Er is in een database makkelijker structuur aan te brengen dan in een systeem met text files.

het gaat om een online shop waarvan de producten vaak genoeg zullen wisselen. ik dacht het eerst ook uit een db telezen, maar omdat ik bang ben dat de site dan te traag wordt denk ik aan optie 1&2 uit files lezen...heb wel getest om uit db te lezen, locaal werkt het best snel maar ik weet niet of de performance achteruit gaat als het op de echte server staat.

[Verwijderd]

Ik raad je zeker MySQL aan, ik ben zelf ondertussen al bezig met mijn 3e online winkel voor een klant en heb nog geen problemen van snelheid (meer als 500 producten in de database). En als het op een server staat kun je meestal ook gewoon lokaal verbinding maken omdat de MySQL server meestal op dezelfde machine geinstalleerd is

[Johnny]

Voor een webshop zou ik 100% zeker een database nemen.

Stel, je hebt een tekstbestand met enkele honderden producten, prijzen en beschrijvingen, dan moet dat hele bestand iedere keer helemaal worden geopend, doorzocht en gegevens worden geselecteerd.

Het is ongelofelijk tijdsintensief om zoiets te maken en onderhouden.

Over snelheid hoef je je echt geen zorgen te maken als je bij een degelijke hoster zit. Mocht je echt problemen hebben met de performance dan zou je nog kunnen gaan cachen (veel gevraagde gegevens uit de databse in een tekstbestand zetten en dat includen).

[Alex]

Een webshop wordt niet traag als je maximaal 25 queries per pagina doet. Of je server moet zo brak zijn dat een simpele join al teveel moeite is.
Maar zeker als de content veel wisseld zijn filesystems erg foutgevoelig, daarbij is een database query stukken sneller als een file-include.

[djluc]

Je kunt voor een shop vaak de artikelpagina's gewoon cachen, dan kost het je vrijwel geen load. Je hebt hier hele goede systemen voor die je zonder extra programmeren kunt gebruiken.

[pjonk]

Zoals mijn voorgangers ga voor een Database. MySQL is in de meeste gevallen voldoende tenzij je hogere eisen stelt aan je DBMS (bijvoorbeeld als je transactions wilt gebruiken of een hoge userload hebt).

Als je op je database daarbij de juiste indexen legt is de performance (zeker bij grote tabellen) vaak veel beter dan bij text files.

[Verwijderd]

Verwijderd schreef op 30 november 2003 @ 11:31:
Ik raad je zeker MySQL aan, ........bezig met mijn 3e online winkel voor een klant en heb nog geen problemen van snelheid (meer als 500 producten in de database). ....

Andere vraag voor jouw, wat doe je met de info in je mandje? Slaa je dat iedere in je db, of zet je ze in een SESSIE , COOKIE en dan pas als de gebruiker uitlog of uit checked naar de db?

[Verwijderd]

hhhmmmmm ik ben bijna overtuigd van het gebruik van een db (MySQL), performance, flexibiliteit en beheerbaarheid is errug belangrijk voor mij, omdat ik die site zelf moet beheren, dus dan zou de db idd de beste oplossing zijn

, maar ik zit toch echt met het probleem dat het mijn performance zal aantasten, omdat de data base behoorlijk groot gaat worden omdat er konstant nieuwe producten en informatie bij komen...

Met files kan ik dat denk ik beter beheren, maar dat is idd veel werk...

[ixi]

Kijk naar tweakers.net -> draait ook op een mysql database, en is denk ik toch net een slagje groter en complexer dan wat jij gaat maken (statistisch gezien grote kans iig).

Elk artikel krijgt een nummer, zodra iemand dit artikel in z'n winkelwagen zet kan je het beste sessions gebruiken denk ik. Is redelijk eenvoudig om een array met artikel nummer en aantal in de sessions te duwen.

$_SESSION['basket'][$artnr] = $aantal

zoiets..

[MisterData]

Ik heb ook alles in een database voor mijn CMS Ik heb daarnaast caching gemaakt: op het moment dat een pagina veranderd wordt deze in de cache opgeslagen en kan het .php script de cache (een .html file) lezen en aan de client doorgeven. Dat ontlast de database-server weer Over het algemeen ben ik goed te spreken over de performance

[Verwijderd]

ik zal hier naar gaan kijken

[Verwijderd]

ff over die database, mysql 4.0.x cacht toch gewoon queries die hetzelfde zijn? Ik neem aan dat het niet extreem veel performance gaat kosten om dit uit een database te halen, al helemaal met dit in je achterhoofd?

[drm]

D_Original:
maar ik zit toch echt met het probleem dat het mijn performance zal aantasten, omdat de data base behoorlijk groot gaat worden omdat er konstant nieuwe producten en informatie bij komen...

Kleine hint: hoe denk je dat dit forum werkt?

[Eelke Spaak]

Verwijderd schreef op 30 november 2003 @ 14:42:
hhhmmmmm ik ben bijna overtuigd van het gebruik van een db (MySQL), performance, flexibiliteit en beheerbaarheid is errug belangrijk voor mij, omdat ik die site zelf moet beheren, dus dan zou de db idd de beste oplossing zijn

, maar ik zit toch echt met het probleem dat het mijn performance zal aantasten, omdat de data base behoorlijk groot gaat worden omdat er konstant nieuwe producten en informatie bij komen...

Met files kan ik dat denk ik beter beheren, maar dat is idd veel werk...

Een paar SQL-queries per pagina zijn doorgaans wel sneller dan een paar file-includes per pagina.

Daarnaast kan je een database (met de goeie programmatuur) veel makkelijker beheren dan een collectie tekstbestanden.

[MisterData]

Verwijderd schreef op 07 december 2003 @ 14:25:
ff over die database, mysql 4.0.x cacht toch gewoon queries die hetzelfde zijn? Ik neem aan dat het niet extreem veel performance gaat kosten om dit uit een database te halen, al helemaal met dit in je achterhoofd?

Als MySQL die query cached dan zou dat inderdaad niet uit moeten maken, maar als je de database server niet op fysiek dezelfde webserver draait kan het wel uitmaken (de webserver moet dan namelijk verbinding leggen met de database server over netwerk)

[Verwijderd]

MisterData schreef op 07 december 2003 @ 17:05:
[...]


Als MySQL die query cached dan zou dat inderdaad niet uit moeten maken, maar als je de database server niet op fysiek dezelfde webserver draait kan het wel uitmaken (de webserver moet dan namelijk verbinding leggen met de database server over netwerk)

och die paar kilobyte over een 100mbit netwerk met een ping van ca 0,8ms durf ik wel aan

Servers van tweakers.net draaien nu ook zo, en die zijn echt vrij zwaar belast

[ Voor 7% gewijzigd door Verwijderd op 07-12-2003 22:30 ]

[Tom-my]

en maak anders een testcase. Stel een demo database op (dus een database zoalstie ongeveer zou moeten zijn incl (nuttitge) test data). Ga vervolgens met timers is testen wat er sneller is?

[Verwijderd]

Benchmark on a table with 38567 rows:

mysql_fetch_array
MYSQL_BOTH: 6.01940000057 secs
MYSQL_NUM: 3.22173595428 secs
MYSQL_ASSOC: 3.92950594425 secs

mysql_fetch_row: 2.35096800327 secs
mysql_fetch_assoc: 2.92349803448 secs

As you can see, it's twice as effecient to fetch either an array or a hash, rather than getting both. it's even faster to use fetch_row rather than passing fetch_array MYSQL_NUM, or fetch_assoc rather than fetch_array MYSQL_ASSOC. Don't fetch BOTH unless you really need them, and most of the time you don't.

zijn de benchmarks niet server afhankelijk? en de constructie van je queries??

[ Voor 12% gewijzigd door Verwijderd op 08-12-2003 17:34 ]

[Verwijderd]

100% database.

Ik snap uberhaupt niet waarom je voor iets anders zou kiezen voor een shop. Volgens mij (verbeter me maar als ik het fout heb) ligt de performance van de website niet in hoe snel de database (mysql, mssql, oracle etc) is, maar hoe je hele database structuur is opgezet.

Ik heb paketten gezien die per pagina bijna 200 queries uitvoeren. Merk je niets van. Hoe kan dat? -> doordachte database structuur. DBA is niet voor niets een apart vak waarin je je kunt specialiseren.

Hetzelfde principe als goede code schrijven wat je ook moet doen met je queries
Slechte queries zorgen ook vaak voor vertraging en niet de database.

Dacht je werkelijk dat grote forums en sites als amazon, bol, marktplaats, ebay etc. etc. zonder database zouden bestaan?

Nogmaal, de snelheid zit hem niet in de database maar in hoe je ZELF jouw database opzet.

Ik wil wel eens zien wat er gebeurt als er ineens 100 man tegelijk allemaal die tekstbestanden gaan oproepen (en dan moet je er ook nog in kunnen zoeken). Ughhh alleen het idee al.....

Tuurlijk speelt de snelheid van de server wel een rol maar dat doet ie ook met textbestanden.
Das in ieder geval hoe ik er over denk

[ Voor 5% gewijzigd door Verwijderd op 08-12-2003 17:54 ]

[Suepahfly]

Als je een heavy-traffic site verwacht met veel en snel wisselende data, dan zou ik voor een database kiezen.

bvk. memorybased tables, deze zijn sneller met resultaat geven als diskbased tables.

Dan denk ik niet aan MySQL maar eerder postgre.
Heap tabellen (MySQL) slaan nl. helemaal geen data op de schijf op, dus server plat -> data kwijt. Postgre doet dit geloof ik wel.

Als je toch mysql kiest dan zou ik toch zeker innoDB tabellen gaan, deze hebben nl. record locking, myisam niet.

Dit zou afdoende moeten zijn, GoT maakt ook gebruik van MySQL icm innoDB.

[Verwijderd]

Verwijderd schreef op 08 december 2003 @ 17:53:
100% database.

Ik snap uberhaupt niet waarom je voor iets anders zou kiezen voor een shop. Volgens mij (verbeter me maar als ik het fout heb) ligt de performance van de website niet in hoe snel de database (mysql, mssql, oracle etc) is, maar hoe je hele database structuur is opgezet.

Ik heb paketten gezien die per pagina bijna 200 queries uitvoeren. Merk je niets van. Hoe kan dat? -> doordachte database structuur. DBA is niet voor niets een apart vak waarin je je kunt specialiseren.

......
Das in ieder geval hoe ik er over denk

[/quote]

effe voor de duidelijkheid, voor mij backend gebruik ik een db natuurlijk. wat ik me afvroeg is aan de ene zijds, of ik dus plain statische text ( du de plain site content) ook vanuit de db zal lezen of niet, omdat dit soort text toch niet zo snel/frequent zal veranderen dacht ik aan files, om de db niet te veel te belasten, anderzijds dacht ik aan de db omdat dat meer flexibiliteit geef mbt maintenance. Maar zoals ik al zei de site content zal niet zo frequent veranderen...dus

maar ik begin meer te denken dat ik voor "alles" db kant op ga

[Verwijderd]

Zekerweten een databeest gebruiken!

Ik heb een online winkel gemaakt voor een school opdracht.
Voor het winkelmandje heb ik een koekje gebruikt. Er staat op phpfreakz.nl een kleine uitleg over koejes en online winkels: webwinkel

Veel succes ermee!!

[Verwijderd]

Suepahfly schreef op 08 december 2003 @ 20:21:
Als je een heavy-traffic site verwacht met veel en snel wisselende data, dan zou ik voor een database kiezen. bvk. memorybased tables, deze zijn sneller met resultaat geven als diskbased tables.

dit is idd de bedoeling

Dan denk ik niet aan MySQL maar eerder postgre.
Heap tabellen (MySQL) slaan nl. helemaal geen data op de schijf op, dus server plat -> data kwijt. Postgre doet dit geloof ik wel.

Als je toch mysql kiest dan zou ik toch zeker innoDB tabellen gaan, deze hebben nl. record locking, myisam niet.

Dit zou afdoende moeten zijn, GoT maakt ook gebruik van MySQL icm innoDB.

ik ga idd hier effe een kijk je nemen thnx voor deze uitleg