[PHP/(My)SQL] voor dummies - deel 60

Index

» digital corner

actieve topics nieuwe topics
abonnement Unibet Coolblue Bitvavo
pi_59438001
quote:
Op dinsdag 10 juni 2008 09:06 schreef ursel het volgende:
Ik heb er eerlijk gezegd ook nog niet eerder over gehoord. En jou PHP versie volgens mij ook niet
In Java is het wel mogenlijk.
Steam - SC2
pi_59438857
quote:
Op maandag 16 juni 2008 18:13 schreef super-muffin het volgende:

[..]

In Java is het wel mogenlijk.
Correct, maar Java is geen PHP
fokstok.nl
pi_59439133
quote:
Op maandag 16 juni 2008 16:34 schreef SuperRembo het volgende:
De laatse 60 gebruikers die online waren, gesorteerd op naam:
[ code verwijderd ]

Is de naam echt de key tussen online en profielen?

Het verschil in dagen tussen twee datums krijg je in één keer met DATEDIFF(dat1, dat2).
Bedankt voor je query SR, maar helaas support de host van mijn klantje geen subqueries... waarom stappen ze nou niet gewoon allemaal gelijktijdig over!!

en datediff wist ik wel maar ook weer niet tnx

En heeft iemand nog een antwoord op deze vraag?
[PHP/(My)SQL] voor dummies - deel 60
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  maandag 16 juni 2008 @ 19:19:32 #106
107951 JortK
Immer kwaliteitsposts
pi_59439656
quote:
Op maandag 16 juni 2008 18:50 schreef Light het volgende:

[..]

Correct, maar Java is geen PHP
Daar valt geen speld tussen te krijgen nee
Overzicht van alle maandcijfers van het fokforum, voor de stats freaks!
Een goede Fok!search met de kracht van Google!
pi_59439770
ik snap het niet....
Je moet dus je users joinen op de online tabel, en alles wat daar niet in staat is dus offline?
pi_59441192
quote:
Op maandag 16 juni 2008 19:22 schreef Xcalibur het volgende:
ik snap het niet....
Je moet dus je users joinen op de online tabel, en alles wat daar niet in staat is dus offline?
Klopt 100%
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_59442790
In dat geval denk ik niet dat het met een enkele query lukt, met twee moet geen probleem zijn....:)
Met een JOIN op IS NULL kan je de subquery omzeilen.
pi_59444148
quote:
Op maandag 16 juni 2008 19:00 schreef Chandler het volgende:
[..]
Bedankt voor je query SR, maar helaas support de host van mijn klantje geen subqueries... waarom stappen ze nou niet gewoon allemaal gelijktijdig over!!
Zeg dat dan meteen
Dan zou je eerst een temp tabel kunnen vullen met de laatste 60 online id's... maar dan is het eenvoudiger om eerst alle rows uit te lezen en ze dan in php te sorteren.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
pi_59444329
quote:
Op maandag 16 juni 2008 11:18 schreef ursel het volgende:
Weet er iemand eigenlijk wat een beetje de limieten van MySQL zijn?
Voor aantal connecties heb ik ooit wel eens opgevangen dat MySQL beetje gaat hikken als die meer dan 100 connecties per seconde krijgt bijvoorbeeld.

Maar hoe zit het eigenlijk met de hoeveelheid data?
Weet dat we nu nog met 400 mb nog makkelijk niet aan de max zitten. Maar voor een project zijn we het een en ander aan het inventariseren om toch grotere hoeveelheden data op te gaan slaan.

Met het oog op de toekomst wel zo prettig om dan ook gelijk de database te evalueren.
hoe goed geindexeerd is die 400mb
  dinsdag 17 juni 2008 @ 00:12:34 #112
63192 ursel
"Het Is Hier Fantastisch!
pi_59449352
quote:
Op maandag 16 juni 2008 21:47 schreef morpheus_at_work het volgende:

[..]

hoe goed geindexeerd is die 400mb
Wat is de definitie van goed.
Kan beter, maar wel deels. Wat zal ik zeggen.

Er liggen op de belangrijkste en grootste tabellen wel indexen, maar is de engine momenteel nog myisam. Er liggen bijvoorbeeld geen foreign keys.
De engine zal in de nieuwe toevoer ook uitgezocht worden en denk momenteel innoDB hier voor te gebruiken.
Maar de nieuwe data opslag zal een ander process zijn dan de huidige. Eigenlijk willen we van een ander systeem maandelijks de data opslaan en deze doorzoekbaar maken voor slechts enkele gebruikers. De hoeveelheid queries zullen dus miniem zijn, de hoeveelheid te zoeken data groot.
  dinsdag 17 juni 2008 @ 01:49:23 #113
187069 slacker_nl
Sicko pur sang
pi_59450524
-edit-

Fixed.

[ Bericht 99% gewijzigd door slacker_nl op 17-06-2008 02:12:59 ]
In theory there is no difference between theory and practice. In practice there is.
pi_59452844
quote:
Op maandag 16 juni 2008 20:56 schreef Xcalibur het volgende:
In dat geval denk ik niet dat het met een enkele query lukt, met twee moet geen probleem zijn....:)
Met een JOIN op IS NULL kan je de subquery omzeilen.
Hoe bedoel je met IS NULL? ik heb geen ervaring met lege JOINS
quote:
Op maandag 16 juni 2008 21:41 schreef SuperRembo het volgende:
Zeg dat dan meteen
Dan zou je eerst een temp tabel kunnen vullen met de laatste 60 online id's... maar dan is het eenvoudiger om eerst alle rows uit te lezen en ze dan in php te sorteren.
Ja ik denk dat het laatste idd de oplossing is, ik ga er mee aan de slag! tnx!
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_59453826
quote:
Op dinsdag 17 juni 2008 09:39 schreef Chandler het volgende:
[..]
Hoe bedoel je met IS NULL? ik heb geen ervaring met lege JOINS
Vaak kan je een WHERE IN (...) of WHERE NOT IN (...) sub query omzetten naar een JOIN. In dit geval lukt dat niet omdat in de sub query een ORDER BY en LIMIT zit.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
pi_59453920
quote:
Op dinsdag 17 juni 2008 10:25 schreef SuperRembo het volgende:
Vaak kan je een WHERE IN (...) of WHERE NOT IN (...) sub query omzetten naar een JOIN. In dit geval lukt dat niet omdat in de sub query een ORDER BY en LIMIT zit.
Volgens mij kan je die ORDER BY en LIMIT in de gewone query doen?
Je krijgt sowieso alleen de resultaten van je JOIN, en die worden dan gesorteerd en gelimit.

Chandler: zie ook de uitleg hier: http://dev.mysql.com/doc/refman/4.1/en/join.html
4e bullet gaat over de IS NULL syntax
pi_59455078
quote:
Op dinsdag 17 juni 2008 10:29 schreef Xcalibur het volgende:

[..]

Volgens mij kan je die ORDER BY en LIMIT in de gewone query doen?
Je krijgt sowieso alleen de resultaten van je JOIN, en die worden dan gesorteerd en gelimit.
Het probleem is in dit geval dat je voor de LIMIT wil sorteren op online.id, maar voor de regels die daarmee gevonden worden wil je op profielen.naam gesorteerd hebben.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
pi_59455273
Volgens mij is dat niet waar, aangezien uitsluitend de online users in de online tabel staan. Als je deze tabel joint krijg je dus alle online users. Als je deze met IS NULL joint krijg je alle offline users.

Er hoeft op die manier dus niet gelimit / gesorteerd te worden op de online tabel


Edit: je hebt dus wél twee queries nodig, 1 voor de online en 1 voor de offline users....
pi_59497259
quote:
Op zondag 15 juni 2008 01:19 schreef qu63 het volgende:
Dan moet die } op regel 19/20
Dit heeft helaas ook niet mogen baten. Ik houd het wel bij het oude script. Weinig spam tot nu toe .
  woensdag 18 juni 2008 @ 20:11:27 #120
62215 qu63
..de tijd drinkt..
pi_59497641
quote:
Op woensdag 18 juni 2008 19:58 schreef JJasperO het volgende:

[..]

Dit heeft helaas ook niet mogen baten. Ik houd het wel bij het oude script. Weinig spam tot nu toe .
Dan weet ik het ook niet
It's Time To Shine
[i]What would life be like without rhethorical questions?[/i]
pi_59501837
quote:
Op dinsdag 17 juni 2008 00:12 schreef ursel het volgende:

[..]

Wat is de definitie van goed.
Kan beter, maar wel deels. Wat zal ik zeggen.

Er liggen op de belangrijkste en grootste tabellen wel indexen, maar is de engine momenteel nog myisam. Er liggen bijvoorbeeld geen foreign keys.
De engine zal in de nieuwe toevoer ook uitgezocht worden en denk momenteel innoDB hier voor te gebruiken.
Maar de nieuwe data opslag zal een ander process zijn dan de huidige. Eigenlijk willen we van een ander systeem maandelijks de data opslaan en deze doorzoekbaar maken voor slechts enkele gebruikers. De hoeveelheid queries zullen dus miniem zijn, de hoeveelheid te zoeken data groot.
Dan zijn goede indices wel belangrijk. Zeker omdat je in een grote hoeveelheid data wilt zoeken.

Als je 1.000.000 unieke getallen hebt en je zoekt daar een specifiek getal zonder dat je weet hoe de rij gesorteerd is, dan heb je gemiddeld 500.000 pogingen nodig (gewoon vooraan beginnen, en steeds de volgende pakken tot je de goede hebt gevonden). Als je weet dat de rij oplopend gesorteerd is, heb je maximaal 20 pogingen nodig (aangenomen dat je nauwkeurig het midden kunt bepalen). Als je zoekt op een getal dat niet in de lijst staat, heb je in het eerste geval altijd 1.000.000 zoekpogingen nodig, in het tweede geval nog steeds niet meer dan 20.

Indices in MySQL werken vast iets anders, maar een goede index heeft een zeer groot effect op de snelheid. En hoe groter je dataset, hoe groter het voordeel.
fokstok.nl
pi_59547099
Een leuke ;)

Voor een bepaald script dat ik include moet ik weten waar het script staat (directory).

voorbeeld:

include("./templates/test/test.php");

nu moet het script (test.php) weten dat het pad ./templates/test/ is om daar zijn bestanden te kunnen benaderen.

Nu doe ik het zo

1$_SERVER['DOCUMENT_ROOT'] . pathinfo($_SERVER['SCRIPT_NAME'], PATHINFO_DIRNAME) . "/pixel.gif"


maar dat vind ik niet echt lekker werken en aangezien ik op een online webserver geen DOCUMENT_ROOT (denk ik) kan gebruiken ben ik opzoek naar een andere oplossing.

Iemand die mij kan helpen?
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_59547233
1
2
3		<?php
include(dirname(__FILE__).'/templates/test/test.php');
?>
fokstok.nl
pi_59547522
@Light; het idee is goed, maar wil dat het script test weet waar het staat.

Gaat niet om het include script maar om het script dat geincluded wordt
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_59547570
quote:
Op vrijdag 20 juni 2008 12:28 schreef Light het volgende:

[ code verwijderd ]
Zonder de /templates dir neem ik aan.
pi_59547610
quote:
Op vrijdag 20 juni 2008 12:43 schreef Scorpie het volgende:

[..]

Zonder de /templates dir neem ik aan.
Kan, ligt aan de directorystructuur
fokstok.nl
pi_59547755
quote:
Op vrijdag 20 juni 2008 12:40 schreef Chandler het volgende:
@Light; het idee is goed, maar wil dat het script test weet waar het staat.

Gaat niet om het include script maar om het script dat geincluded wordt
Als in het directorypad op de server? Met dirname(__FILE__) krijg je de directory (zonder /) waarin het bestand met die code zich bevindt. Dus als je dat in test.php gebruikt dan weet test.php waar het staat.
fokstok.nl
  vrijdag 20 juni 2008 @ 13:15:38 #128
63192 ursel
"Het Is Hier Fantastisch!
pi_59548550
quote:
Op woensdag 18 juni 2008 22:08 schreef Light het volgende:

[..]

Dan zijn goede indices wel belangrijk. Zeker omdat je in een grote hoeveelheid data wilt zoeken.

Als je 1.000.000 unieke getallen hebt en je zoekt daar een specifiek getal zonder dat je weet hoe de rij gesorteerd is, dan heb je gemiddeld 500.000 pogingen nodig (gewoon vooraan beginnen, en steeds de volgende pakken tot je de goede hebt gevonden). Als je weet dat de rij oplopend gesorteerd is, heb je maximaal 20 pogingen nodig (aangenomen dat je nauwkeurig het midden kunt bepalen). Als je zoekt op een getal dat niet in de lijst staat, heb je in het eerste geval altijd 1.000.000 zoekpogingen nodig, in het tweede geval nog steeds niet meer dan 20.

Indices in MySQL werken vast iets anders, maar een goede index heeft een zeer groot effect op de snelheid. En hoe groter je dataset, hoe groter het voordeel.
De methode van indices is mij wel bekend ja

Waar ik vooral naar op zoek ben zijn de eventuele beperkingen in MySQL wanneer je met grote hoeveelheden aan de slag gaat.
pi_59548658
quote:
Op vrijdag 20 juni 2008 13:15 schreef ursel het volgende:

[..]

De methode van indices is mij wel bekend ja

Waar ik vooral naar op zoek ben zijn de eventuele beperkingen in MySQL wanneer je met grote hoeveelheden aan de slag gaat.
Ligt er natuurlijk aan wat je bedoelt met 'aan de slag gaan', het sorteren van, zoeken in, updaten van.
  vrijdag 20 juni 2008 @ 13:42:36 #130
63192 ursel
"Het Is Hier Fantastisch!
pi_59549339
quote:
Op vrijdag 20 juni 2008 13:18 schreef Thomass het volgende:

[..]

Ligt er natuurlijk aan wat je bedoelt met 'aan de slag gaan', het sorteren van, zoeken in, updaten van.
Gewoon het gehele proces. Ik heb eigenlijk nog nooit met grote hoeveelheden data hoeven werken en dus ook nooit problemen hoeven ondervinden in MySQL.

De planning voor het nieuwe project is dat er maandelijk zo'n 50 - 100 mb aan data in de database opgeslagen moet gaan worden. Echter is het de bedoeling dat in de loop der jaren al deze data doorzoekbaar moet blijven.

Ik ben dus vooral op zoek naar informatie wat een beetje de limieten zijn als data veel gaat worden, queries moeilijker te doorzoeken worden etc.
Ik bedoel, ergens zal er toch wel een reden zijn waarom je over zou stappen van de gratis MySQL naar een dure Oracle of andere betaalde database server.
  vrijdag 20 juni 2008 @ 13:49:45 #131
107951 JortK
Immer kwaliteitsposts
pi_59549548
quote:
Op vrijdag 20 juni 2008 13:42 schreef ursel het volgende:

[..]

Gewoon het gehele proces. Ik heb eigenlijk nog nooit met grote hoeveelheden data hoeven werken en dus ook nooit problemen hoeven ondervinden in MySQL.

De planning voor het nieuwe project is dat er maandelijk zo'n 50 - 100 mb aan data in de database opgeslagen moet gaan worden. Echter is het de bedoeling dat in de loop der jaren al deze data doorzoekbaar moet blijven.

Ik ben dus vooral op zoek naar informatie wat een beetje de limieten zijn als data veel gaat worden, queries moeilijker te doorzoeken worden etc.
Ik bedoel, ergens zal er toch wel een reden zijn waarom je over zou stappen van de gratis MySQL naar een dure Oracle of andere betaalde database server.
Een database van 50 - 100 mb gaat gewoon goed, mits natuurlijk je je datamodel wel op orde hebt.

Ik heb zelf een database van 13GB, ook dit werkt nog perfect
Overzicht van alle maandcijfers van het fokforum, voor de stats freaks!
Een goede Fok!search met de kracht van Google!
  vrijdag 20 juni 2008 @ 14:07:33 #132
63192 ursel
"Het Is Hier Fantastisch!
pi_59550095
quote:
Op vrijdag 20 juni 2008 13:49 schreef JortK het volgende:

[..]

Een database van 50 - 100 mb gaat gewoon goed, mits natuurlijk je je datamodel wel op orde hebt.

Ik heb zelf een database van 13GB, ook dit werkt nog perfect
Database groeit per maand met die hoeveelheid..
Maar dan nog duurt het dus ff eer ik bij de 13 GB ben..

Weet ik in ieder geval dat me daar geen zorgen voor hoef te maken. Bedankt..
pi_59551337
quote:
Op vrijdag 20 juni 2008 13:15 schreef ursel het volgende:

[..]

De methode van indices is mij wel bekend ja

Waar ik vooral naar op zoek ben zijn de eventuele beperkingen in MySQL wanneer je met grote hoeveelheden aan de slag gaat.
Dat ligt aan je definitie van groot. FOK! draait op MySQL. En alleen al het forum heeft ruim 59 miljoen posts. Als je dat combineert met veel pageviews dan wordt het allemaal wat lastiger qua setup enzo. Pageviews van het forum weet ik niet, maar in de tijd dat ik crew was, was een subsite met 100.000 pageviews per dag klein.
fokstok.nl
  vrijdag 20 juni 2008 @ 15:36:38 #134
63192 ursel
"Het Is Hier Fantastisch!
pi_59552415
Ik vertrouw er dus wel op dat mijn project geen probleem moet wezen voor MySQL.
Maar wat zijn dan de voordelen om een dure databaseserver als Oracle te nemen bijvoorbeeld?
pi_59554511
quote:
Op vrijdag 20 juni 2008 12:23 schreef Chandler het volgende:
Een leuke

Voor een bepaald script dat ik include moet ik weten waar het script staat (directory).

voorbeeld:

include("./templates/test/test.php");

nu moet het script (test.php) weten dat het pad ./templates/test/ is om daar zijn bestanden te kunnen benaderen.

Nu doe ik het zo
[ code verwijderd ]

maar dat vind ik niet echt lekker werken en aangezien ik op een online webserver geen DOCUMENT_ROOT (denk ik) kan gebruiken ben ik opzoek naar een andere oplossing.

Iemand die mij kan helpen?
Ik doe het zo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25		<?php
// env.php 
$BASEDIR = "/home/wesleys/sbox/php";
$LIBDIR  = "$BASEDIR/lib";
$BINDIR  = "$BASEDIR/bin";
$LIB_OPN = "$LIBDIR/OPN";
$LIB_OTH = "$LIBDIR/OTHERS";
$SMARTY  = "/usr/share/php/smarty/libs";

include_once("$LIB_OPN/Util.php");
/* set_path zit in Util.php */

set_path($LIBDIR, $BINDIR, $LIB_OPN, $LIB_OTH);

function set_path() {
        $args = func_get_args();
        $incl_path = "include_path";
        $include_path = ini_get($incl_path);
        foreach ($args as $val) {
                /* add check to see if path exists */
                $include_path .= ":$val";
        }
        return ini_set($incl_path, "$include_path");
}
?>


Ik kan nu op devolgende manieren includen:

1
2
3
4
5
6
7
8
9		<?php
//index.php
include_once("/path/to/env.php");

// Includen allemaal dezelfde file.
include_once("/path/to/OPN/Util.php");
include_once("OPN/Util.php");
include_once("Util.php");
?>


En dit kan je daarna in alle files doen die door index.php geinclude worden. Util.php kan ik nu ook include_once("Something.php") doen zonder me hoef druk te maken over het pad waar de file instaat.

Bijkomend voordeel is dat ik alle files in OPN/lib gewoon include_once("File.php") kan gebruiken zonder set_path omdat alle files die geinclude worden in de huidige dir zitten. Mocht je iets uit OTHERS of SMARTY willen hebben dan moet je wel eerst env.php includen. Of je include_once("../OTHERS/File.php");

Ikzelf vind deze werkwijze erg prettig, aangezien ik maar in 1 file hoef bij te houden welke include paden ik wil, en doordat de rest gewoon geinclude wordt hoef ik me daar niet meer druk te maken over owje.. Waar stond dat ookalweer? Gewoon include_once("File.php") en je bent klaar.

[ Bericht 8% gewijzigd door slakkie op 20-06-2008 17:27:19 ]
pi_59612096
Stel je wilt gegevens van meerdere websites opslaan en maandelijks genereer je 10MB aan data per website (gemiddeld) zou je dan kiezen voor een database er website of 1 database voor alle sites? (meerdere website is 1 tot 10.000)

Waarvoor zou jij kiezen en leg eens uit waarom je kiest voor jou keuze.

Poll: 1 of meer databases?
  • 1 database
  • Meerdere databases

    Resultaten:
    • The people who lost my respect will never get a capital letter for their name again.
    Like trump...
    pi_59612994
    Meerdere databases. Ik neem aan dat de websites sowieso al gebruik maken van een database, en daar kan best een extra tabel in voor de statistiekjes.
    fokstok.nl
    pi_59613272
    Je wil misschien ook vergelijkingen en statistieken kunnen tonen over meerdere sites en dan is het vele malen praktischer als alle data in 1 database zit. Er is m.i. geen enkele goede reden om dit in meerdere databases te doen. Als het om 1 tot 10.000 sites gaat dan raakt het overzicht zo zoek als je dat opsplitst.
    pi_59613365
    quote:
    Op zondag 22 juni 2008 22:36 schreef Farenji het volgende:
    Je wil misschien ook vergelijkingen en statistieken kunnen tonen over meerdere sites en dan is het vele malen praktischer als alle data in 1 database zit. Er is m.i. geen enkele goede reden om dit in meerdere databases te doen. Als het om 1 tot 10.000 sites gaat dan raakt het overzicht zo zoek als je dat opsplitst.
    Dan zou je het niet alleen in 1 database maar ook in 1 tabel moeten houden. Kan makkelijk natuurlijk.
    fokstok.nl
      zondag 22 juni 2008 @ 22:43:41 #140
    3677 SuperRembo
    Sinds 1998
    pi_59613509
    Het ligt er ook maar net aan wat je uiteindelijk wil doen met al die data.
    Wil iedereen die in telekinese gelooft nu mijn hand op steken?
    | Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
    pi_59620425
    Tja wat wil ik met al die data doen?! statistieken genereren dat doe ik trouwens al met ipCounter.nl echter is deze database te log om te benutten.

    voorbeeld: http://www.gfxstat.com/count/testtest.png

    Verder had ik deze vraag ook op WmCity gesteld: http://www.wmcity.nl/forum_topic.php?id=631195&page=1#631238 en daar zijn de keuzes ook verdeeld qua 1 database t.o.v. meerdere databases.



    [ Bericht 17% gewijzigd door Chandler op 23-06-2008 10:40:00 ]
    The people who lost my respect will never get a capital letter for their name again.
    Like trump...
      maandag 23 juni 2008 @ 11:20:59 #142
    187069 slacker_nl
    Sicko pur sang
    pi_59621550
    1 DB, en wellicht zou ik het nog in 1 table knallen ook.
    In theory there is no difference between theory and practice. In practice there is.
    pi_59621592
    Waarom gebruik je niet gewoon Google Analytics of zo'n soort programma?
    Het wiel opnieuw uitvinden heeft bij zoiets vrij weinig toegevoegde waarde volgens mij?
      maandag 23 juni 2008 @ 11:31:58 #144
    85919 Likkende_Lassie
    Doe eens wat aan je ondertitel
    pi_59621826
    1 Database,

    Zoals hier bovengezegt, vergelijken wordt makkelijk enz. En mij lijkt ook het updaten van de tabel structuur een stuk makkelijker/sneller te gaan!
    pi_59622405
    quote:
    Op maandag 23 juni 2008 10:31 schreef Chandler het volgende:
    Tja wat wil ik met al die data doen?! statistieken genereren
    Maar wil je alleen statistieken per website maken, of wil je ook statistieken over alle websites heen maken. In het tweede geval is 1 grote db waarschijnlijk handiger, anders is 1 db per website waarschijnlijk handiger en sneller.
    Wil iedereen die in telekinese gelooft nu mijn hand op steken?
    | Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
      maandag 23 juni 2008 @ 12:18:47 #146
    187069 slacker_nl
    Sicko pur sang
    pi_59622893
    Hoezo zouden meerdere databases het zooitje handiger maken als je per website wat wilt doen? 1 storage plek voor deze data lijkt me meer dan voldoende. De website specifieke shizzle fix je met je SQL code..

    select * from table where site = $sitename; en dus bist klaar. Om voor elke site naar een andere DB te connecten en dan select * from table te gaan doen lijkt me de boel alleen maar onnodig moeilijk maken.

    Basicly heb je 1 table nodig met daarin de values en de stats genereer je dynamisch in je PHP.. Je moet alleen de juiste data fetchen, magic doen, output printen. Een aparte DB voor elke site.. overkill.
    In theory there is no difference between theory and practice. In practice there is.
      maandag 23 juni 2008 @ 12:32:34 #147
    87680 Mirel
    Mirel wil een bongophone.
    pi_59623198
    Hoi, phpdummy hier , voor een portfolio opdracht voor school ben ik eventueel van plan om met een uploadform een foto up te loaden naar een fotomapje, en dan is het de bedoeling dat die foto op een andere pagina automatisch te zien zal te zijn.
    Ik heb er eigenlijk niet eens zoveel verstand van, maar ik begrijp dus dat wanneer er op de uploadknop geklikt wordt, dat de foto naar het mapje gaat, en een link ervan in een tabel (?), zodat er op de portfolio pagina die tabel uitgelezen kan worden.

    Nou is mij de vraag, als de foto geupload is, dan moet de link ervan naar de tabel, en niet het bestand zelf. En hoe laat je het precies zien op de pagina? Op het moment dat ie geupload is, dat ie op de pagina te zien is.
    When all else fails, you always have delusion.
    pi_59623381
    quote:
    Op vrijdag 20 juni 2008 17:03 schreef slakkie het volgende:

    [..]

    Ik doe het zo:
    [ code verwijderd ]

    Ik kan nu op devolgende manieren includen:
    [ code verwijderd ]

    En dit kan je daarna in alle files doen die door index.php geinclude worden. Util.php kan ik nu ook include_once("Something.php") doen zonder me hoef druk te maken over het pad waar de file instaat.

    Bijkomend voordeel is dat ik alle files in OPN/lib gewoon include_once("File.php") kan gebruiken zonder set_path omdat alle files die geinclude worden in de huidige dir zitten. Mocht je iets uit OTHERS of SMARTY willen hebben dan moet je wel eerst env.php includen. Of je include_once("../OTHERS/File.php");

    Ikzelf vind deze werkwijze erg prettig, aangezien ik maar in 1 file hoef bij te houden welke include paden ik wil, en doordat de rest gewoon geinclude wordt hoef ik me daar niet meer druk te maken over owje.. Waar stond dat ookalweer? Gewoon include_once("File.php") en je bent klaar.
    Ziet er handig uit, maar wat nou als er 2 bestanden het zelfde heten in een van de ingestelde directories?
    Steam - SC2
    pi_59625591
    quote:
    Op maandag 23 juni 2008 11:20 schreef slacker_nl het volgende:
    1 DB, en wellicht zou ik het nog in 1 table knallen ook.
    Ik gebruik ruim 10 tabellen voor veel verschillende informatie onderdelen oa. user/browser/os/iprange/country/referer/hits&uniques en ga zo maar door
    quote:
    Op maandag 23 juni 2008 11:22 schreef Xcalibur het volgende:
    Waarom gebruik je niet gewoon Google Analytics of zo'n soort programma?
    Het wiel opnieuw uitvinden heeft bij zoiets vrij weinig toegevoegde waarde volgens mij?
    Dan snap ik niet dat google ooit groot is geworden? Juist door het wiel op nieuw uit te vinden kun je het verbeteren anders reden we nog steeds op houten wielen

    Maar ik lees dat 1DB gewoon toch handiger is! en ga deze wijze raad toch opvolgen!

    Mijn huidige DB (van ipCounter) gebruik zo'n 500KB per 2000 unieke gebruikers en hun gegevens
    De nieuwe database van gfxstat zal 50KB per 2000 unieke gebruikers bevatten, tevens zullen er geen dubbele gegevens worden opgeslagen wat in het geval van ipCounter wel zo was. (referers per dag, nu referers totaal plus een tabel die linkt per dag!)
    The people who lost my respect will never get a capital letter for their name again.
    Like trump...
      maandag 23 juni 2008 @ 14:19:49 #150
    187069 slacker_nl
    Sicko pur sang
    pi_59625635
    quote:
    Op maandag 23 juni 2008 12:40 schreef super-muffin het volgende:
    Ziet er handig uit, maar wat nou als er 2 bestanden het zelfde heten in een van de ingestelde directories?
    Voorbeeld:

    Util.php zit in zowel /path/to/lib/OPN als /path/to/lib/Others

    Dan moet je weten welk pad als eerste in in je include_path zit:

    include_path=/path/to/lib:/path/to/lib/OPN:/path/to/lib/Others

    Dan zal hij altijd de Util.php uit lib/OPN pakken, omdat deze eerder wordt gedefinieerd. Mocht je de Util uit de andere dir willen hebben dan moet je deze expliciet includen: include_once("Others/Utils.php"). Vandaar ook dat ik /path/to/lib include, zodat ik dit soort trucjes kan uithalen.

    Persoonlijk zou ik er dan voor kiezen om 1 vd 2 bestanden te renamen (wellicht je eigen versie, aangezien je daar mee controle op hebt). Maar dit is niet altijd mogelijk... Dus expliciet includen..
    In theory there is no difference between theory and practice. In practice there is.
    pi_59626352
    @slakkie: ik ga jouw functie ook gebruiken, thx !
    pi_59627907
    quote:
    Op maandag 23 juni 2008 14:17 schreef Chandler het volgende:
    Dan snap ik niet dat google ooit groot is geworden? Juist door het wiel op nieuw uit te vinden kun je het verbeteren anders reden we nog steeds op houten wielen
    Mja, alleen zijn er inmiddels al dermate veel (en goede!) statistiekenprogramma's, al dan niet gratis, dat ik me toch echt de moeite zou besparen van al die ellende zelf uit te zoeken

    Als je iets beters dan Google Analytics hebt gefabriceerd hou ik me overigens wel aanbevolen
      maandag 23 juni 2008 @ 16:42:55 #153
    187069 slacker_nl
    Sicko pur sang
    pi_59629206
    quote:
    Op maandag 23 juni 2008 14:50 schreef Scorpie het volgende:
    @slakkie: ik ga jouw functie ook gebruiken, thx !
    Kewl :)


    Een toegift dan ;)

    1
    2
    3
    4
    5
    6
    7
    8
    9    		<?php
    function req_version($version) {
            if (    version_compare(PHP_VERSION, $version, '<' ) == 1) {
                        trigger_error(sprintf("Required version is %s, you have %s\n", $version, PHP_VERSION),
    E_USER_ERROR);
                    exit(    255);
            }
    }
    ?>

    In env.php roep ik deze ook aan:

    req_version("5.2.1"); en dan gaat ie barfen als je een versie lager dan 5.2.1 gebruikt..

    Die heb ik geschreven aanzien ik onder Perl ook kan aangeven, require $version:

    require v5.6.1; # run time version check
    require 5.6.1; # ditto
    require 5.006_001; # ditto; preferred for backwards compatibility

    Dat kan uiteraard niet ontbreken in PHP ;)
    In theory there is no difference between theory and practice. In practice there is.
    actieve topics nieuwe topics
    abonnement Unibet Coolblue Bitvavo
    [PHP/(My)SQL] voor dummies - deel 60
    Index

    » digital corner

    Forum Opties
    Forumhop:
    Hop naar:
    (afkorting, bv 'KLB')