Comment by cmrdporcupine | Hacker News Reader

Comment by cmrdporcupine | Hacker News Reader

Parent Full thread

Data models are restrictive

That's kind of the point. Model your data. Think about it. Don't (mis)treat your database as a "persistence layer" -- it's not. It's a knowledge base. The "restriction" in the relational model is making you think about knowledge, facts, data, and then structure them in a way that is then more universal and less restrictive for the future.

Relations are very expressive and done right is far more flexible than the others named there. That was Codd's entire point:

https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf

"Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation) ..." and then goes on to explain how the predicate-logic based relational data model is a more universal and flexible model that protects users/developers from the static impositions of tree-structured/network structure models.

All the other stuff in this article is getting stuck in the technical minutiae of how SQL RDBMSs are implemented (author seems obsessed with indexes). But that's somewhat beside the point. A purely relational database that jettisons SQL doesn't have to have the limitations the author is poking at.

It's so frustrating we're still going over this stuff decades later. This was a painful read. People developing databases should already be schooled in this stuff.

If Postgres was already horizontally scalable and supported incrementally maintained recursive CTEs (like Materialize can do) then I could see how Rama would be mostly uninteresting to a seasoned SQL developer, but as it is I think Rama is offering a pretty novel & valuable set of 3GL capabilities for developers who need to build scalable reactive applications as quickly as possible. Capabilities which other SQL databases will struggle to match without also dropping down to 3GL APIs.

> A purely relational database that jettisons SQL doesn't have to have the limitations the author is poking at.

Agreed. Relational databases can take us a lot further yet.

In their chosen example, and many others that involves external sources, it's not really "your" data, though. You have no control over the structure, and you then have the choice of deciding whether you want to throw away what you can't shoehorn into your current schema, or store it and transform it as best you can and be prepared to re-transform it as your system evolves.

Really, they're not avoiding modelling the data. They're modelling it in their "P-stores" whether they want to admit that's just another data model or not. It's clearly not data models they object to, but typical database DDL coupled with a desired to not throw away data that doesn't conform right now. Depending on your application domain, not throwing away data that doesn't conform to your current data model can be good or bad, but it's not an accident that they picked Twitter/Mastodon where it's easy to justify not rejecting non-conforming documents.

I agree with you that this doesn't require ditching relational models, though. For that matter not even SQL. You can even fairly easily build this kind of architecture without e.g. ever leaving Postgres (replicated pair for their "depots"; triggers + postgres foreign data wrappers to materialize views on index servers and/or to do requests across index servers).

> "Future users of large data banks..."

Nothing in Rama prevents you from doing that. You just see it through the SQL lens and your entire point is invalid.

Problem with your asinine response is I hate SQL and don't particularly see through that lense at all?

I just happen know what a "relation" is, while the author doesn't seem to.

> our database as a "persistence layer" -- it's not. It's a knowledge base.

Love this. Your database is your app in my opinion. The data model matters.

"Data outlives the application".

Precisely this. Every “solution” I’ve seen approaches RDBMS as an obviously incorrect kludge that must be done away with in the name of DX.

RDBMS hasn’t stuck around this long only because it’s good enough. It’s an incredibly powerful way to model data, for now and the future, but yes, it does require you to think carefully and slow down. These are not things to be avoided.

Yes, the core of the problem with people "getting it" has always been that SQL has been so mediocre, and yet it's the only serious option people have.

And so people go looking for something with a modern syntax, that's properly composable, functional, etc. but because they haven't studied the foundations, they reinvent the wheel badly.

The Codd paper is so readable, and so persuasive. People need to start there, and then argue why their novel approach is better on first principles, not just because it smells better than SQL.

But that it's stuck around and done so well for so long tells you that the core foundation is sound.

At the beginning of the article, the "relational" database is described as a particular architecture ("map of maps, with secondary indexes being additional maps") without recognizing that the other given examples ("key/value", "document" and "column-oriented") are also relational and the differences are only, at worst, performance tradeoffs.

The more I read it the less it makes sense.

Reply on news.ycombinator.com