[fpc-pascal] Working on a new way to educate people about pascal

[geneb]

On Thu, 29 Dec 2022, Anthony Youngman via fpc-pascal wrote:

> On 29/12/2022 12:31, Anthony Walter via fpc-pascal wrote:
>> @youngman
>> 
>> "I'm a database guy with maybe 30 years experience, I'm new to SQL and 
>> oh my god is it an over-complicated monster ..."
>> 
>> Wait, what? Something doesn't make sense with what you said. You have 30 
>> years of experience writing database programming code AND you are 
>> just now beginning to learn about SQL?
>
I gotta stick my oar in here, sorry guys. ;)

SQL is just one kind of database technology.  I've been programming for 
money since 1988(ish) and my career focus has been multi-value/nosql 
databases.  MV is a huge player in the background, but the industry as a 
whole couldn't market its way out of a wet paper bag if you handed it a 
sharp stick.  High per-seat licensing fees don't help this. (ScarletDME 
aims to put an end to that nonsense, at least for some folks.)

> Well, may I suggest you actually COMPREHEND Richter's point when he said 
> "and only a very small part of people who use Databases use SQL".
>
> I guess you've never heard of NoSQL databases then? As in "No SQL"?
>
It may just be that he's in the SQL Silo, where other database systems 
simply don't exist.  It happens.

> Most of my programming has been done using databases that were what? 
> maybe five years old before SQL was even thought of! Yes you can use 
> SQL, but why bother when you have a much more expressive, powerful and 
> comprehensible language at your finger tips.
SQL showed up in 1972.  The progenitor to multi-value databases (GIRLS) 
appeared in 1965.  So yeah, SQL is the new kid. ;)

>> 
>> Also, it helps a whole lot when writing SQL if you format your statements:
>> 
>> select
>>      c.*,
>>      cc.country_name
>> from
>>      customers c
>>      join country_codes cc on cc.country_code = c.country_code;
>> 
>> Formatting code really helps legibility, especially when it comes to 
>> SQL. That ought to be one of the first things you learn.
>

That makes my eye twitch.  Not because of how it's formatted, but because 
of the gyrations required to reach the data you want.

> LIST CUSTOMERS WITH COUNTRY_CODE EQ "USA"
>
There's more going on here than meets the eye (or there could be).

> All the crap in your select statement - INCLUDING the join - has been 
> pushed down into the *table* definition (not the view, the table).
>

MV/NoSQL systems (the good ones, anyway) use a thing called a dictionary. 
In Anthony's example above, COUNTRY_CODE is a dict (dictionary) item.  It 
can be a couple of different things - it could be pointing to the 
attribute in the customer record that contains the value for the country 
code, or it could be pointing to a country code file that utilizes the 
customer number (or whatever the item name is for a customer in the 
customer file) as a key to an item in the country code file.

The SQL syntax can be horribly complex due to requirements imposed by 
"join" to reach items in other tables.  With ENGLISH (or sometimes 
ACCESS), the syntax is greatly simplified because all the heavy lifting is 
done by dict items - it could be as simple as formatting a field for 
output, or as complex as making a function call to code that pulls data 
from a hardware device connected to a network.

I need to stop now as I fear I've driven the topic drift to the end-stops, 
but I'm quite sure that if you (or anyone else!) would like to know more 
about MV database systems, Anthony & I could answer any question you 
have...off list (to the joy of the moderators I suspect. :D )

g.


-- 
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!