Python sets, frozensets, and literals

Posted Jan 24, 2022 9:42 UTC (Mon) by james (subscriber, #1325)
In reply to: Python sets, frozensets, and literals by NYKevin
Parent article: Python sets, frozensets, and literals

NYKevin wrote:

I would much rather have invoice line items sorted (by name, by serial number, or by some other reasonable thing such as total or individual price) than in "natural" order.

Well,

if you have a large / technically savvy customer, you'll be providing the invoice in a machine-readable format so order doesn't matter;
if you have a customer who is actually checking off lines on a piece of paper or a PDF against their purchase order, they'll thank you if the lines on the invoice are in the same order as they were in the purchase order;
if they want invoice lines sorted in any particular way, they'll probably want to sort the order that way, too.

Python sets, frozensets, and literals

Posted Jan 24, 2022 19:58 UTC (Mon) by Wol (subscriber, #4433) [Link] (2 responses)

And that to me exemplifies one of the biggest problems with the relational mindset. The developer dictates what is acceptable, starting with C&D's statement that "data comes in rows and columns". (NYKevin is trying to dictate the structure of an invoice - which works fine for the customer ledger, but not for the purchase ledger. Actually, it doesn't even work for the customer ledger - the customer might well decide to become an ex-customer ...)

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.

Pick strongly separates such metadata from the data - in fact I would go as far as to say mixing the two together in the same data structure is a *major* design blunder. Yet relational analysis absolutely demands that you mingle the two so the database can't tell the difference. WTF??? Imho if the database can't tell the difference between external data and internal deduction something is well off.

The poor relational business analyst is given the nightmare task of bashing square pegs into round holes.

(One nice thing about Pick is that it does, however, use the exact same structure to store metadata and data. Each level of the tree is metadata for the level below it. I'm pretty sure relational actually does the same under the covers, but it's much more hidden and obscure.)

Think xml and dtd, where the data is "unstructured" and the definition is separate. Pick beat xml to it by about 30 years...

Cheers,
Wol

Python sets, frozensets, and literals

Posted Feb 6, 2022 23:26 UTC (Sun) by flussence (guest, #85566) [Link] (1 responses)

> 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