Python sets, frozensets, and literals

Posted Feb 6, 2022 23:26 UTC (Sun) by flussence (guest, #85566)
In reply to: Python sets, frozensets, and literals by Wol
Parent article: Python sets, frozensets, and literals

> But no data doesn't come in rows and columns. It's an unstructured mess that comes from the user. And any structure that you derive from it is METAdata.

I... don't think that's the job of the average RDBMS to begin with, ostensibly at least? It stores data in a shape computers would prefer, and it has assertions to stop out-of-range values being inserted so readers can assume it's a source of truth without reverifying everything (unless you're unfortunate enough to have mysql), but everything else - the heavy lifting of getting user input, pulling it apart into that shape, reassembling it for the user afterwards - is *supposed to* be done in a real programming environment outside the DB.

I'll admit though that's often not how it goes in the real world, and I've seen far too many “clever” things done in relational stuff just because it was possible. A lot of people learned carpentry with the PHP hammer, and SQL servers nowadays are full of power tools without guidance on appropriate uses for them. I guess I agree with you about the bashing square pegs into round holes.

Python sets, frozensets, and literals

Posted Feb 7, 2022 0:25 UTC (Mon) by Wol (subscriber, #4433) [Link]

You're confusing DATABASES with RELATIONAL DATABASES. They are NOT the same thing.

There are plenty of other databases out there, object, tree, multi-value, etc etc.

Relational won because Oracle invested in marketing. Pick lost because Dick Pick invested in litigation.

But anything relational can do I can do with Pick. Faster, less hardware, less cpu power, ... AND I HAVE THE MATHS TO PROVE IT.

Einstein said "make things as simple as possible BUT NO SIMPLER". I would argue, very forcefully, that Relational Databases are TOO simple, with the result that the application layer on top has to be more complex, and the net result is that the system AS A WHOLE is much more complicated than it need be.

I'm quite happy to agree with you that it's not the job of a RELATIONAL database to manage the metadata. The problem is, it requires the Business Analyst to MUDDLE UP DATA AND METADATA, which then makes it hell for the programmer.

Because Pick DOES manage data and metadata SEPARATELY, thats why we can hold a schema in our head that would blow the mind of a relational guy. Because we're not actually holding the entire schema, we only need to hold the bit that's relevant to our problem (the relational guy doesn't know what bit IS relevant!). If I'm looking at INVOICE, then everything I need is in the DICTionary (at least it should be, if the previous programmer did his job properly!)

Cheers,
Wol