Is this a good idea?

[sam.s.kong]

Hi!

I've been programming ASP for 5 years and am now learning PHP.
In ASP, you can use GetRows function which returns 2 by 2 array of
Recordset.
Actually, it's a recommended way in ASP when you access DB as it
disconnects the DB earlier.
Also, it's handy as you can directly access any data in the array
without looping.

As far as I know, there's no such function in PHP and I can make one.
My question is whether it's good in PHP.

pseudo-code:

$data = get_data("selec t * from table1");
$var = $data[3][2]; //value at 4th row, 3rd column

This way, I can wrap db connection, data retrieval, and error handling
with one function (or maybe a class).
Is the idea workable?

TIA.
Sam

[Iván Sánchez Ortega]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chung Leong wrote:

[refactoring] [...] By definition, you are not adding new
functionality--hence value to the product. You are thus wasting
programming and QA resource. Moreover, you risk introducting bugs into
what was working before. It's a lose-lose proposition.

As every good engineer knows, if it ain't broken, don't fix it.
But, if it's broken, I'd better fix it for good, instead of patching legacy
code so that it "just works".

The isue we're discussing - dumping the entire query results into an array
in memory - induces lazyness in the programmers. Lazyness leads to more
complex code, more complex code leads to more bugs, more bugs leads to more
wasted QA time when something breaks down.

A few MB of memory per script may seem a small issue, but think about a
few MB per script, 100 scripts per second.

That's just unrealistic. When you retrieve data from the database, it
usually goes somewhere--i.e. to the client.

Sometimes it does not - sometimes, due to lazy programming or bad DB design,
data goes into memory, goes out of memory. And the whole thing risks
becoming a GIGO.

(but, hey, it's a "it just works" scenario! it's good for the CEO! I'm
getting paid!)
In you scenario you'd have a server that output multiple gigs per-second.
I don't know about you but I certainly don't have a peta-byte bandwidth
quota.

No; in my scenario I'll just have a couple of Gigabit-ethernet-enabled
servers. And their bottleneck must be the bandwith, not the resource-hungry
scripts. The code must be so flazing fast, so fucking clean, that I'm able
to affirm the server will be able to handle the load and not choke.

- --
- ----------------------------------
Iván Sánchez Ortega -i-punto-sanchez--arroba-mirame-punto-net

Donde se pierde el interés también se pierde la memoria.
-- Johann Wolfang Von Goethe. (1749-1832) Escritor alemán.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD0DdA3jc Q2mg3Pc8RAmqiAJ 0RdFNwsQZ1jGA2I pAl71RHNq44RQCf aJtK
gLEzeA51A7KxtWq tK9hxBW0=
=HcH0
-----END PGP SIGNATURE-----

[Iván Sánchez Ortega]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

R. Rajesh Jeba Anbiah wrote:

<OT>It's really nice to see new comers like Iván Sánchez Ortega
and the c.l.php discussions are now getting hotter:-)</OT>

Newcomer? I've been programming in PHP long before you were born, bro!

:-P

- --
- ----------------------------------
Iván Sánchez Ortega -i-punto-sanchez--arroba-mirame-punto-net

Las personas obran por interés propio. Incluso cuando servimos a los demás,
solemos hacerlo porque nos reporta beneficios o porque no hacerlo iría en
nuestro propio detrimento. Aunque las personas sacrifiquen su vida por el
prójimo en tiempos de guerra y otras circunstancias extremas, no puede
decirse que ésta sea la norma. Habitualmente, por no decir ante todo, el
altruismo satisface una necesidad propia.
-- Thomas Hobbes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD0DeH3jc Q2mg3Pc8RAkPFAJ 9oenvM626ctrD+n sZktN0ieNz6WQCd G+kL
sZZ+qmt51cKoA9a 0Zbeyvzw=
=Snkm
-----END PGP SIGNATURE-----

[R. Rajesh Jeba Anbiah]

Iván Sánchez Ortega wrote:

R. Rajesh Jeba Anbiah wrote:

<OT>It's really nice to see new comers like Iván Sánchez Ortega
and the c.l.php discussions are now getting hotter:-)</OT>

Newcomer? I've been programming in PHP long before you were born, bro!

Hey:-)

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

[Jerry Stuckle]

Iván Sánchez Ortega wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chung Leong wrote:


But, if it's broken, I'd better fix it for good, instead of patching legacy
code so that it "just works".

The isue we're discussing - dumping the entire query results into an array
in memory - induces lazyness in the programmers. Lazyness leads to more
complex code, more complex code leads to more bugs, more bugs leads to more
wasted QA time when something breaks down.

I disagree completely.

There are many valid reasons for putting the information in an array.

For one thing - once you have it in an array, you can release your
result set - freeing MySQL resources. And if you don't need the
connection for anything else, you can close it. One of the big
concurrency issues with RDB's is holding their resources longer than
necessary.

Also, if you're doing lots of complex processing on the returned data,
it's generally better to buffer the data in your own program rather than
hold it in MySQL.

Your way works for low volume web pages. But once you get into heavy
database use, it's a whole different story.

Sometimes it does not - sometimes, due to lazy programming or bad DB design,
data goes into memory, goes out of memory. And the whole thing risks
becoming a GIGO.

(but, hey, it's a "it just works" scenario! it's good for the CEO! I'm
getting paid!)

You don't need local buffering to make a GIGO. Any poor programming
practice will do it. While no good programming practice will.

No; in my scenario I'll just have a couple of Gigabit-ethernet-enabled
servers. And their bottleneck must be the bandwith, not the resource-hungry
scripts. The code must be so flazing fast, so fucking clean, that I'm able
to affirm the server will be able to handle the load and not choke.

Try it on some of the systems I've worked on in the past. Multiple web
servers feeding off one database server (DB/2 on AIX in this case).
Averages of < 100K > 1M hits/hr.

I've also worked on database systems which can handle peaks of < 1M
database requests per hour. You can't do either if you hold the db
resources unnecessarily long.
- --
- ----------------------------------
Iván Sánchez Ortega -i-punto-sanchez--arroba-mirame-punto-net

Donde se pierde el interés también se pierde la memoria.
-- Johann Wolfang Von Goethe. (1749-1832) Escritor alemán.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD0DdA3jc Q2mg3Pc8RAmqiAJ 0RdFNwsQZ1jGA2I pAl71RHNq44RQCf aJtK
gLEzeA51A7KxtWq tK9hxBW0=
=HcH0
-----END PGP SIGNATURE-----

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Jerry Stuckle]

Iván Sánchez Ortega wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

R. Rajesh Jeba Anbiah wrote:

<OT>It's really nice to see new comers like Iván Sánchez Ortega
and the c.l.php discussions are now getting hotter:-)</OT>

Newcomer? I've been programming in PHP long before you were born, bro!

:-P

- --
- ----------------------------------
Iván Sánchez Ortega -i-punto-sanchez--arroba-mirame-punto-net

Las personas obran por interés propio. Incluso cuando servimos a los demás,
solemos hacerlo porque nos reporta beneficios o porque no hacerlo iría en
nuestro propio detrimento. Aunque las personas sacrifiquen su vida por el
prójimo en tiempos de guerra y otras circunstancias extremas, no puede
decirse que ésta sea la norma. Habitualmente, por no decir ante todo, el
altruismo satisface una necesidad propia.
-- Thomas Hobbes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD0DeH3jc Q2mg3Pc8RAkPFAJ 9oenvM626ctrD+n sZktN0ieNz6WQCd G+kL
sZZ+qmt51cKoA9a 0Zbeyvzw=
=Snkm
-----END PGP SIGNATURE-----

And I've was probably programming before you were born!

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Chung Leong]

Iván Sánchez Ortega wrote:

But, if it's broken, I'd better fix it for good, instead of patching legacy
code so that it "just works".
Then it's not refactoring, my friend.
The isue we're discussing - dumping the entire query results into an array
in memory - induces lazyness in the programmers. Lazyness leads to more
complex code, more complex code leads to more bugs, more bugs leads to more
wasted QA time when something breaks down.
There we go. That's something that always happen in this group--when
unable to afford a defense on technical merits, resort to a value
judgement of sort. There's nothing wrong in choosing an easy solution.
It's called being smart.
Sometimes it does not - sometimes, due to lazy programming or bad DB design,
data goes into memory, goes out of memory. And the whole thing risks
becoming a GIGO.
Using bad programming to justify your so-called "good programming"--now
you're making a whole of sense.
No; in my scenario I'll just have a couple of Gigabit-ethernet-enabled
servers. And their bottleneck must be the bandwith, not the resource-hungry
scripts. The code must be so flazing fast, so fucking clean, that I'm able
to affirm the server will be able to handle the load and not choke.

You don't even know what you're debating. The exact same amount of work
is done. There is no performance impact unless the memory usage exceeds
the physical amount available. A typical database query will return 10K
or less. To say that reading the data into an array would somehow have
some castatrophe effect on performance is...intellectu ally challenged.

[R. Rajesh Jeba Anbiah]

Chung Leong wrote:
<snip>

There is no performance impact unless the memory usage exceeds
the physical amount available. A typical database query will return 10K
or less. To say that reading the data into an array would somehow have
some castatrophe effect on performance is...intellectu ally challenged.

Some crazy predictions of the future of this thread:
Chung gonna prove his ideas with his own (benchmarking?) script and I
gonna ask him to use APD and other real tools, some curmudgeon gonna
claim more than 100 years of experience without reading the thread, and
.....

(Discussions in c.l.php are not that hard to imagine;-) Pun intended,
not meant to be serious.)

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

[Chung Leong]

R. Rajesh Jeba Anbiah wrote:

Some crazy predictions of the future of this thread:
Chung gonna prove his ideas with his own (benchmarking?) script and I
gonna ask him to use APD and other real tools, some curmudgeon gonna
claim more than 100 years of experience without reading the thread, and
....

What I am going to say is this: *never* listen to the advice of R.
Rajesh Jeba Anbiah because it will shrink your dick. Unless someone can
prove otherwise (benchmarking?) , we should assume my assertion is true.

[Chung Leong]

Jerry Stuckle wrote:

For one thing - once you have it in an array, you can release your
result set - freeing MySQL resources. And if you don't need the
connection for anything else, you can close it. One of the big
concurrency issues with RDB's is holding their resources longer than
necessary.

Also, if you're doing lots of complex processing on the returned data,
it's generally better to buffer the data in your own program rather than
hold it in MySQL.

It doesn't have to be complex, just time-consuming. An operation like
echo can potentially block for a very long time.

[R. Rajesh Jeba Anbiah]

Chung Leong wrote:

R. Rajesh Jeba Anbiah wrote: <snip> What I am going to say is this: *never* listen to the advice of R.
Rajesh Jeba Anbiah because it will shrink your dick. Unless someone can
prove otherwise (benchmarking?) , we should assume my assertion is true.

LOL:-)

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/