[PHP] num_rows of fetchen

[ Voor 196% gewijzigd door gorgi_19 op 26-06-2007 13:07 ]

Saven schreef op dinsdag 26 juni 2007 @ 13:08:
Oke thnx mensen, dat verklaart een hoop

Verwijderd schreef op dinsdag 26 juni 2007 @ 13:11:
Overigens klopt de code ook niet.

In het eerste geval zal $a een array bevatten en echo $a dus niet zo gek veel doen, in het tweede geval zal $a een integer bevatten.

Erkens schreef op dinsdag 26 juni 2007 @ 13:12:
[...]

daarom wordt er dus ook de eerste entry uit die array ge-echo-ed

[ Voor 5% gewijzigd door Verwijderd op 26-06-2007 13:25 ]

Saven schreef op dinsdag 26 juni 2007 @ 13:44:
[...]

Op de PHP website staat dat fetch_array enzo sneller is

Saven schreef op dinsdag 26 juni 2007 @ 13:44:
[...]

Op de PHP website staat dat fetch_array enzo sneller is

Saven schreef op dinsdag 26 juni 2007 @ 13:44:
[...]

Op de PHP website staat dat fetch_array enzo sneller is

string mysql_result ( resource $result, int $row [, mixed $field] )

Retrieves the contents of one cell from a MySQL result set.

When working on large result sets, you should consider using one of the functions that fetch an entire row (specified below). As these functions return the contents of multiple cells in one function call, they're MUCH quicker than mysql_result(). Also, note that specifying a numeric offset for the field argument is much quicker than specifying a fieldname or tablename.fieldname argument.

Verwijderd schreef op dinsdag 26 juni 2007 @ 13:56:
Als id een autonummering is, dan zou

code:

1	$q = mysql_query("SELECT id FROM forum limit 1");

wellicht nog sneller werken?

Verwijderd schreef op dinsdag 26 juni 2007 @ 13:56:
Als id een autonummering is, dan zou

code:

1	$q = mysql_query("SELECT id FROM forum limit 1");

wellicht nog sneller werken?

[ Voor 11% gewijzigd door Janoz op 26-06-2007 14:07 ]

Verwijderd schreef op dinsdag 26 juni 2007 @ 14:09:
Ok, maar is het sneller?

1

$q = 40000;

Janoz schreef op dinsdag 26 juni 2007 @ 14:25:
[...]

Als het je om snelheid gaat doe je gewoon:

PHP:

1	$q = 40000;

Stuk sneller dan jouw oplossing.

Blacksnak schreef op dinsdag 26 juni 2007 @ 14:30:
[...]


die reactie is ook duidelijk

Creepy schreef op dinsdag 26 juni 2007 @ 16:05:
[...]
wat had je dan verwacht?

REDFISH schreef op dinsdag 26 juni 2007 @ 18:34:
Is mysql_fetch_object niet nog wat netter?

AlainS schreef op dinsdag 26 juni 2007 @ 22:10:
Ik bedoel:

Je hebt 1 miljoen records en 100 keer per seconde wordt gevraagd hoeveel records er zijn. Ga je dan een teller gebruiken om bij te houden hoeveel records er zijn of doe je dat pas bij een miljard records. Of misschien helemaal niet.

De vraag is: Hoe ga je bepalen wanneer je voor een teller kiest i.p.v. de COUNT functie in mysql?

AlainS schreef op dinsdag 26 juni 2007 @ 22:10:
Ik bedoel:

Je hebt 1 miljoen records en 100 keer per seconde wordt gevraagd hoeveel records er zijn. Ga je dan een teller gebruiken om bij te houden hoeveel records er zijn of doe je dat pas bij een miljard records. Of misschien helemaal niet.

De vraag is: Hoe ga je bepalen wanneer je voor een teller kiest i.p.v. de COUNT functie in mysql?

DRAFTER86 schreef op dinsdag 26 juni 2007 @ 22:20:
[...]


Ik heb geen idee, maar ik zou het niet raar vinden als MySql zelf die teller bijhoud

[ Voor 12% gewijzigd door Gomez12 op 26-06-2007 22:49 ]

Blacksnak schreef op dinsdag 26 juni 2007 @ 16:10:
[...]


Gaat me dan ook niet over wat nu sneller of trage is. Vond het antwoord van Janoz gewoon nogal direct en cru overkomen.

DRAFTER86 schreef op dinsdag 26 juni 2007 @ 22:20:
[...]


Ik heb geen idee, maar ik zou het niet raar vinden als MySql zelf die teller bijhoud

Grijze Vos schreef op dinsdag 26 juni 2007 @ 22:50:
[...]

Is ook niet zo vreemd. Het ID veld gebruiken voor meer dan key identificatie is gewoon ook een doodzonde binnen de database wereld.

AlainS schreef op dinsdag 26 juni 2007 @ 22:10:
De vraag is: Hoe ga je bepalen wanneer je voor een teller kiest i.p.v. de COUNT functie in mysql?

Hydra schreef op woensdag 27 juni 2007 @ 13:46:
Zelf een teller bijhouden vind ik nogal smerig.

Verwijderd schreef op woensdag 27 juni 2007 @ 13:53:
Bij een forum bijvoorbeeld zou je dagelijks een scriptje kunnen laten draaien die alle tellers alsnog goed zet mochten er fouten in zitten. Op die manier maakt de kwaliteit van de software niet meer uit, 1x per dag wordt het in ieder geval goed gezet (er vanuitgaande dat het bij uitzondering mis gaat, niet bij regel).

In een echte professionele applicatie kan zoiets natuurlijk niet door de beugel, je zult er dan voor moeten zorgen dat het gewoon klopt.

Erkens schreef op woensdag 27 juni 2007 @ 13:49:
Soms moet je wel ivm performance met joins, zoals dus al reeds als voorbeeld is genoemd: dit forum met bijvoorbeeld de reply count die in de topics list staan, je wilt echt niet voor elke view al die tellers gaan bepalen, dat is gewoon veel te zwaar voor welke database dan ook.

Grijze Vos schreef op woensdag 27 juni 2007 @ 13:59:
[...]


Waarom niet gewoon met een nette count-query bij een update de daadwerkelijke waarde herberekenen. Dat kost je ook net niks aan performance, maar is wel een stuk robuuster, en dan is je data veel zekerder up to date.

Uiteraard, als je alle scenarios afdekt, dan is een tellertje natuurlijk altijd correct, dat terzijde.

Verwijderd schreef op woensdag 27 juni 2007 @ 16:23:
Je kunt dan met een cronjob ervoor zorgen dat in ieder geval 1x per dag (of vaker of minder vaak, net wat je wilt) de gegevens worden bijgewerkt. Iets als de postcount van een gebruiker maakt in principe weinig uit, het is enkel een idicatie maar mag best 2 a 3 ernaast zitten. Het is alleen nuttig om zoiets te doen als de uitzondering (dus dat het mis gaat) vrij weinig voorkomt, je zult dus toch ervoor moeten zorgen dat het onderliggende systeem zoveel mogelijk klopt anders is de teller niet heel nuttig.

storeman schreef op donderdag 28 juni 2007 @ 10:54:
Whowh, dat scheelt .

Birdie schreef op donderdag 28 juni 2007 @ 23:13:
[...]
Yep, by MyISAM tabellen is die count al opgeslagen (zoals Hydra vermoedde) en wordt er helemaal niet geteld. InnoDB tabellen blijven op dit punt.. een tikje achter

Voutloos schreef op vrijdag 29 juni 2007 @ 08:21:
[...]
Ipv achterblijven kan je het ook een bewuste ontwerpkeuze (gemaakt oa ivm transactions) noemen.

[..]Wat ook handig is, is om je statsgeilheid een beetje in bedwang leren te houden, want vaak vormen dat soort stats niet de belangrijkste feature van je applicatie.

Janoz schreef op vrijdag 29 juni 2007 @ 09:19:
Bij MySQL is alsof je uit een snelle auto of uit een veilige auto kunt kiezen, terwijl alle andere database aanbieders al hebben laten zien dat een veilige snelle auto ook gewoon gemaakt kan worden.

Birdie schreef op vrijdag 29 juni 2007 @ 12:46:
[...]
Gosh.. gevoelige snaar geraakt? Meten is weten .

In het beestje bij de naam noemen zie ik geen statsgeilheid, noch een directe aanbeveling of afkeuring van een engine.

Gelukkig lijkt dat aldaar onderhand ook een klein beetje door te dringen . Alle ogen op Falcon?

Overigens heb ik mijn twijfels bij het gemak waarmee er nu zoveel storage engines ontstaan. Is het een model wat ruimte voor vernieuwing biedt en via natuurlijke selectie succesvol zal zijn, of is het nodeloos de aandacht van ontwikkelaars dun uitspreiden over een dozijn middelmatige engines, in plaats van een of twee echt sterke (door) te ontwikkelen?

Birdie schreef op donderdag 28 juni 2007 @ 23:13:
[...]

Let wel: dit gaat alleen over het tellen van ALLE rijen in een tabel. Maak je een selectie, dan is het met die supersnelheid van MyISAM ook weer gedaan.

1
2
3
4
5
6
7
8

ADOdb->RowCount(): 35988
ADOdb Executed in 33.748525857925

mysql_num_rows: 35988
PHP Executed in 34.012000083923

PhpRows fetch COUNT(1) 35988
PHP Executed in 28.839454174042

1
2
3
4
5
6
7
8

ADOdb->RowCount(): 35988
ADOdb Executed in 12.230320930481

mysql_num_rows: 35988
PHP Executed in 12.112257957458

PhpRows fetch COUNT(1) 35988
PHP Executed in 2.7558028697968