On 26/10/2024 19:01, Charlie Gibbs wrote:

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

On 26/10/2024 05:38, Charlie Gibbs wrote:

On 2024-10-25, rbowman <bowman@montana.com> wrote:

On Fri, 25 Oct 2024 17:32:03 GMT, Charlie Gibbs wrote:

On 2024-10-25, 186282@ud0s4.net <186283@ud0s4.net> wrote:

Being forced to be an Ada programmer - it'd be like one of those >>>>>> legendary Greek tortures of hell ...

Another one is being forced to maintain payroll programs forever.

My personal hell is database programming. Gods know I've done enough of it >>>> but it always feels like shoveling shit against the tide.

I'm proud to say that in 50 years of programming I've managed
to never go near a DBMS.

It was people like you who ensured that in the end I did.

Great. There's plenty of work to go around, and each of us
can find our niche.

Absolutely. I am not interested in writing PERL or Python or Pascal.
It all smells of pee anyway.
I am however deeply interested in modelling things like manufacturing,
sub assemblies, parts, just in time supply , and product costings, all integrated with online orders and sales, and financial reports.

SQL is pretty much as perfect tool for that. Or lets be clear - a
relational database is the perfect tool, and MySQL is only a
*moderately* shit way to access it.

I never bothered learning the more arcane side of SQL because if I ever
managed to get the query right, it was always so abysmally slow that it
was quicker to use a series of simple queries and join them together in application code rather than SQL



--
"I am inclined to tell the truth and dislike people who lie consistently.
This makes me unfit for the company of people of a Left persuasion, and
all women"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 27 Oct 2024 09:46:15 +0000, The Natural Philosopher wrote:

I never bothered learning the more arcane side of SQL because if I ever managed to get the query right, it was always so abysmally slow that it
was quicker to use a series of simple queries and join them together in application code rather than SQL

We had a support person who spent days if not months crafting a query
using about every DB2 scalar function known to man. I forget the DB2
versions but it started to fail on an older one that only allowed a 4k
buffer but worked on the newer ones that handled 8k. Being a series of
CONCATs if anything in the chain returned null the whole thing failed.

It was a work of art that was copied from site to site unchanged because nobody, including myself, could figure it out. When we needed an
equivalent for SQL Server which didn't have some of the matching scalars I
took the programming approach. I use joins sparingly but there reaches a
point where you're being too cute and it's unmaintainable.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 27 Oct 2024 09:46:15 +0000, The Natural Philosopher wrote:

I never bothered learning the more arcane side of SQL because if I ever managed to get the query right, it was always so abysmally slow that it
was quicker to use a series of simple queries and join them together in application code rather than SQL

I have found quite the opposite. Remember that, the more information you
put in the query up front, the more clues you give to the query optimizer.

I was maintaining this application for a client, that had been created for
them by a prior developer who knew PHP, but not much else. They didn’t
seem to know anything about SQL joins.

There was a query page that returned timesheet records for a specified
range of dates. It did a separate query for each day in the range, so the
wider the range, the slower the report became. For example, asking for
records over a six-month range was quite painful, since it would be doing
about 180 separate queries.

I figured out a query that would return all the records in the specified
date range in a single sequence. Result: the page now appeared in a flash,
even for date ranges spanning six months or more.

Another possibly useful thing is to learn how to use the EXPLAIN statement <https://mariadb.com/kb/en/explain/>. If a query is slow, this can be
helpful to figure out where the bottleneck lies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 28 Oct 2024 00:58:34 -0400, 186282@ud0s4.net wrote:

Long back I did extensive development on a PICK-OS based DB called 'Revelation'. It DID do an early version of SQL. It was used for over
a decade.

HOWEVER you never used the SQL beyond the top-level selections
because it was too slow.

Pick wasn’t even a relational database.

Back then, it was quite common to support open standards like SQL with “malicious compliance” -- deliberately make them look worse than your proprietary interface, to “persuade” your users to lock themselves in to your product.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/27/24 5:30 PM, Lawrence D'Oliveiro wrote:

On Sun, 27 Oct 2024 09:46:15 +0000, The Natural Philosopher wrote:

I never bothered learning the more arcane side of SQL because if I ever
managed to get the query right, it was always so abysmally slow that it
was quicker to use a series of simple queries and join them together in
application code rather than SQL

I have found quite the opposite. Remember that, the more information you
put in the query up front, the more clues you give to the query optimizer.

Long back I did extensive development on a PICK-OS based DB
called 'Revelation'. It DID do an early version of SQL. It
was used for over a decade.

HOWEVER you never used the SQL beyond the top-level selections
because it was too slow. Thereafter you used the "advanced"
functions - hidden in the back of the manuals - to access the
indexes and sorting routines and such - because they were ten
or even 100 times quicker.

Oh, they still sell 'Revelation' - DOS based - for about
$300 ... but no support. Nice really, integrated WYSIWYG
text-screen form builder too.

Yes you CAN build a sophisticated query using SQL - but
the syntax is TERRIBLE, hyper-prone to error, oft just
un-readable - and the speed is still bad. Intelligently
join yer OWN damned sets with proper code.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-10-28, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Mon, 28 Oct 2024 00:58:34 -0400, 186282@ud0s4.net wrote:

Long back I did extensive development on a PICK-OS based DB called
'Revelation'. It DID do an early version of SQL. It was used for over
a decade.

HOWEVER you never used the SQL beyond the top-level selections
because it was too slow.

Pick wasn’t even a relational database.

Back then, it was quite common to support open standards like SQL with “malicious compliance” -- deliberately make them look worse than your proprietary interface, to “persuade” your users to lock themselves in to your product.

Not just back then. Today it's evolved into the doctrine of
"embrace, extend, extinguish".

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/28/24 1:09 AM, Lawrence D'Oliveiro wrote:

On Mon, 28 Oct 2024 00:58:34 -0400, 186282@ud0s4.net wrote:

Long back I did extensive development on a PICK-OS based DB called
'Revelation'. It DID do an early version of SQL. It was used for over
a decade.

HOWEVER you never used the SQL beyond the top-level selections
because it was too slow.

Pick wasn’t even a relational database.

Nope. Entirely different philosophy.

I liked it.

All hail multi-value :-)

Put together a little library - 'C' and Pascal and
to a degree even Python - over the years with functions
that do some of the same stuff on data strings you may
find in PICK. Tend to import it, often. Useful.

Hey, even made an abridged version for Ada !

Waste of effort alas ....

Back then, it was quite common to support open standards like SQL with “malicious compliance” -- deliberately make them look worse than your proprietary interface, to “persuade” your users to lock themselves in to your product.

Wasn't 'malicious' ... it's just that PICK was never
really MADE for SQL or its style of finding/sorting stuff.
SQL was an "add-on".

However the initial level selects, they DID save a lot
of time/effort. After that however .....

Anyway, search on "Advanced Revelation". It's still sold.
DOS alas. The 'OpenInsight' follow-on product is VASTLY
more expensive, albeit still MV.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/28/24 1:18 AM, Charlie Gibbs wrote:

On 2024-10-28, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Mon, 28 Oct 2024 00:58:34 -0400, 186282@ud0s4.net wrote:

Long back I did extensive development on a PICK-OS based DB called
'Revelation'. It DID do an early version of SQL. It was used for over
a decade.

HOWEVER you never used the SQL beyond the top-level selections
because it was too slow.

Pick wasn’t even a relational database.

Back then, it was quite common to support open standards like SQL with
“malicious compliance” -- deliberately make them look worse than your
proprietary interface, to “persuade” your users to lock themselves in to >> your product.

Not just back then. Today it's evolved into the doctrine of
"embrace, extend, extinguish".

SQL and flat-file DBs are kind of the all-gobbling
monsters.

But MV is still the better, saner, way to organize many
kinds of data.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)