|
|
Posted by Chung Leong on 01/20/06 07:56
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...intellectually challenged.
Navigation:
[Reply to this message]
|