Hacker News Reader

Comment by mamcx | Hacker News Reader

Note: The relational model (even SQL) is THIS.

Despite the claims, SQL is NOT "schema-fixed".

You can 100% create new schemas, alter them and modify them.

What actual happens is that if you have a CENTRAL repository of data (aka "source of truth"), then you bet you wanna "freeze" your schemas (because is like a API, where you need to fulfill contracts).

SQL have limitations in lack of composability, the biggest reason "NoSQL" work is this: A JSON is composable. A "stringy" SQL is not. If SQL were really around "relations, tupes" like (stealing from my project, TablaM):

    [Customer id:i32, name:Str; 1, "Jhon"]

then developers will have less reason to go elsewhere.

View on HN

Author here. All good points. Yes, you can build a super-structured type system on top of tables. EdgeDB does this well. And you can put JSON into relational columns. Then you might ask what the "type" of that column is? Well, if you want deep types, the row type varies from column to column as the JSON values vary and you have to walk the JSON to determine the type. SQL implementation are beginning to try to do deal with this mess by adding layers on top of tables. We're saying, maybe we should think differently about the problem and build tables on top of types as a special case of a type system. This also gives a very nice way to get data into and out of systems without having to go through the messiness of ODBC and special casing tables vs tuples vs scalars etc.

Normalize to the max then denormalize till you achieve the performance trade-offs you want. That's the rule in relational schema design.

Adding JSON traversal operators and functions helps a lot when you end up denormalizing bits of the schema. It's not hard.

You mentioned EdgeDB in the blog post, too, but I just think you and them are dealing with different problems.

My understanding of EdgeDB is they're mostly trying to make correct data-modeling simpler and more intuitive; to let people model relations in the same way they speak and think about it, rather than having to map to SQL concepts like join tables. I rather like what they're going for, though I haven't used it.

EdgeDB seems to be mostly for business logic and OLTP. They're not trying to deal with arbitrary incoming data that might be outside of the control of the ingestion system. You wouldn't even have an ingestion system with EdgeDB.

This is true and is a limitation of SQL (not of the relational model per-se), and also is part of the problem that SQL is not composable (so you don't have a way to nested table definitions)

I’m not sure what you mean by “composable” here — could you elaborate?

Composable is the ability to define things in the small and combine with confidence.

SQL not allow this:

    by_id := WHERE id = $1
     
    SELECT * | by_id

CTEs provide some pretty useful composability for SQL queries. I find myself using them all the time.

why hasn't someone built a composable flavor of SQL? it seems like a burning need

I would say that in a way, that's what substrait[0] is trying to achieve.

[0]: https://substrait.io

This is what Tutorial D is, but it's never been widely adopted.

Reply on news.ycombinator.com