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_!
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
