Comment by cmrdporcupine | Hacker News Reader

Comment by cmrdporcupine | Hacker News Reader

I have come to the place where I feel like the word "persistence" when applied to data / knowledge / information in this way is almost offensively reductionist and actually ignorant of the background in the field...

... Just going to put this here, since it's clear the world still hasn't read and absorbed this knowledge, 50 years later.

I wish people would stop retreading the same broken paths over and over again.

https://twobithistory.org/2017/12/29/codd-relational-model.h...

https://cs.uwaterloo.ca/~david/cs848s14/codd-relational.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) ... A model based on n-ary relations, a normal form for data base relations, and the concept of a universal data sublanguage are introduced."

Based on my reading, Permazen does insulate the user from the data organisation.

https://github.com/permazen/permazen/wiki/FAQ#architecture

It provides a Java view of the data, and handles translating operations in that later into operations on the underlying stores.

"The Java model layer is a Java-centric, type safe, object-oriented persistence layer for Java applications"

That's exactly the kind of thing Codd was arguing against 50 years ago.

Information does not fit in Java objects. It doesn't want to be stuck (and does not work well) in hierarchical property & inheritance relationships. That's not how knowledge works.

Information (and the human mind) does tend towards working better when formulated in terms of first order / predicate logic. Which is what the relational data model is based upon. SQL is a rather crude approximation of that.

True, but we're talking about persisting Java objects, not relational data or an approximation of human knowledge or whatever. This is a narrower problem space, and one solution is treating the storage layer as a KV store, ignoring the problem of translating queries to SQL or mapping classes to DDL. This library is deliberately throwing away the relational model and its power, and the README acknowledges such.

The answer is to stop persisting Java objects, and start writing applications with relations (facts / propositions) in mind.

The OO stuff I think has gotten in the way of our jobs. When I worked in Java it was a mountain of pointless data/transfer object transformations. Microservices has made this worse. It's a really bad paradigm.

Reply on news.ycombinator.com