I forgot to add. Look at this problem from the APPLICATION'S point of view. Design a (set of) relational tables to store a list of pizzas, and the toppings you need to create those pizzas.
Oh - one of the requirements, for an easily maintainable application, is you MUST NOT MIX data and metadata in the same table. Or store the same data multiple times across several tables.
oh no! I've just specified an impossible requirement!
The problem with mixing data and metadata is that the database has no way of knowing which is which. It's all crucial information, that exists only in the programmer's head. BAD BAD BAD!
But I can do that easily in Pick. Precisely because I can do things in n dimensions, not just 2. The only data I need to store across multiple tables is foreign keys. And even then, I can get away with far less duplication than relational.
Posted Dec 20, 2012 22:26 UTC (Thu) by Wol (guest, #4433)
[Link]
To make the problem more explicit, how do you store a list in an rdbms without mixing data and metadata? IT CAN'T BE DONE, because you can't store a list in a set.
So as soon as your data contains lists, an rdbms is inefficient. Much data consists of lists, does it not?