Monday, September 12, 2016

This Week

1. Quote of the Week
"Data sense-making does not benefit from the relational data model. Dr. Codd’s rules for relational modeling were designed to improve efficiencies in data processing and storage, not to make data more intelligible. In fact, structuring data relationally makes the work of data sensemaking more difficult, which is why Dr. Kimball created dimensional data modeling and also why an entire industry of middleware products emerged to hide the complexities of relational models." --Stephen Few,

2. To Laugh or Cry?

3. Of Interest

And now for something completely different

The PostWest (The future of the West is all behind it)

Religion: the source of morality

Pinch me of the week

Mother Teresa declared a saint before huge crowds in the Vatican

Video of the week

Book of the week (purchase via this link to support this site)



  1. There is certainly a use case for arrays in Postgres but this is not because "which is quite a bit to type and can be tough to get your ORM to generate". If your ORM (fancy name for query generator) can't handle this then it's the wrong tool. In the Python world SQLAlchemy is well worth looking at. For some time now Postgres has supported `recursive`queries for tree generation and, of course, the DB has a plan for optimising these.

    Arrays, hstore and especially binary JSON are useful additions to the Postgres toolkit, where the RDBMS can take advantage of tried and tested tools on non-standard data types. Allows you to add some NoSQL stuff to your application without replacing the stack.

  2. > For some time now Postgres has supported `recursive`queries for tree generation and, of course, the DB has a plan for optimising these.

    Recursive queries require higher logic than FOPL and lose the benefit of declarativity, decidability and physical independence of the RDM. That's why Codd opted for hosted data sublanguages rather that integration into computationally complete language.

    > Arrays, hstore and especially binary JSON

    Such attributes must be defined on simple domains--with no meaningful components whose values are treated as atomic by the data language--which means that the DBMS must support encapsulated operators to treat them as such, or PROPER extensions to the relational algebra. I very much doubt that this is the case and even if it were, that there is sufficient foundation knowledge to do this right.

    This is not a PostgreSQL specific criticism, but of all the DBMS products.

    1. Sure, as you know I'm not a real fan of the any procedural stuff in SQL, was just highlighting the "rabbit hole" in the piece. Support for arrays, etc. can be useful, but as you rightly point out they're basically outside the scope of the data model.

      That said, Postgres' binary JSON support does an excellent job of providing relational-style access for JSON (keys get indexed automatically), which is now such a common format of exchange, especially if the alternative is rolling your own DSL for processing it. for the operators (sorry, I'm not really up to critiquing the relational credentials!)

      But getting people to choose the right tool for the job means they have to understand which tools does what. Add to that, of course, knowing what they want to do… And the whole ORM stuff just tends to kick the can down the road.

    2. First and foremost they must understand the RDM, when they are outside it and what are the implications. THEN they can choose tools rationally, otherwise they operate with blinders.

      This is exacerbated, of course, by the fact that DBMS designers don't understand the RDM either and violate it left and right.

      The result is that the benefits of RDM do not materialize, but because everybody believes they are using relational databases and DBMS's, they blame the consequences on the RDM, defeating all chances of truly relational solutions.

      Vicious cycle due to the substitution of vocational training for education.