Re: The joy of SQL

On 26/10/2024 19:48, Waldek Hebisch wrote:

In alt.folklore.computers Lars Poulsen <lars@cleo.beagle-ears.com> wrote:

On 2024-10-26, The Natural Philosopher <tnp@invalid.invalid> wrote:

On 26/10/2024 02:58, 186282@ud0s4.net wrote:

PHP is fair, but it's not really a good DB
    editing lang.

>
You can say that again. Faced with preparing a huge Comma delimited data
set from a very large database PHP simply died a death
>
I wrote that bit in C.

>
Perl does that very well.

 If you have enough memory.  I was using a Perl program to handle
1.3 MB data file.  The program was running out of memory on 8 MB
machine.  There was some supidity in the design: program was
written as a pipline of two processes, each keeping the whole
dataset in memory.  But also Perl data structures were memory-hungry.
That motivated me to write my own implementation of hash table
(in C), which comfortably stored the data set in available memory.
 Of course, frequently one can do processing just storing "current
line" and Perl allows to do this.  But many examples keep all
data in memory and in my case this was necessery.
 

Yup.
I had the same issues when using PHP.
There exists in a non relational form a database of counties, postcodes and addresses and which political entity is notionally in charge (borough and country councils etc) that I needed to turn into a relational database.
MySQL  couldn't do it. Or at least a day later it hadn't.
Neither could PHP.
But I wrote a C program in a couple of hours that would do the job, and do it in about an hour, so after three iterations to sort out the unpleasantness of town names like 'John O' Groats' and a few other issues, I had my database...
--
"I guess a rattlesnake ain't risponsible fer bein' a rattlesnake, but ah puts mah heel on um jess the same if'n I catches him around mah chillun".