21–30 of 81 posts
This is how I do relational databases in 2019. My database is a self contained module more akin to an rpc api than a database. My code has virtually no database logic in it at all. I don't know but it feels like functional databases could be a thing. We should call Martin Fowler and ask.
This is how datomic ions work, i think.
Earlier quoted context omitted.
You may find Graphile interesting https://www.graphile.org/
I prefer https://hasura.io Instead of JS, it's written in Haskell (end user does not write haskell). It's incredibly performant and has hooks for database events. Another similar tool is http://postgrest.org/en/v6.0/
Why do you prefer it? Performance? Features? Ease-of-use?
This is how I do relational databases in 2019. My database is a self contained module more akin to an rpc api than a database. My code has virtually no database logic in it at all. I don't know but it feels like functional databases could be a thing. We should call Martin Fowler and ask.
How is that not how databases are typically used?
Furthermore about everybody knows how to use an ORM. Not many people can write store procedures. Maybe the question is why is that so. I heard "I know [language], I don't know SQL, so I write queries in [language] " so many times even from people I would have expected to have a much broader knowledge. (That also applies to networking technology, they know HTTP and nothing more.)
By the way the code doesn't address authentication and authorization, those go in the layer between the client and the database.
Why are stored procs still used? My experience with the black hole (or really I should say not in version control) pushed me away from them.
It does everything in SQL - header parsing, HTTP routing, and even includes a micro templating engine for generating pages.
I'm curious if anybody has practical experience developing a reasonably trafficked website in a similar manner. I wrote apps which consisted mostly of oracle stored procedures when I first got out of college, and it was a pretty awful experience, but it was also at a place where the development knowledge was minimal. I've since been getting closer and closer to writing postgres in this way. My current app (which I ar…
Every once in a while I encounter somebody who heavily promotes that way of working. There are a couple of arguments I've heard in favor of it. Often it's a mix of performance, ultimate data integrity, and "simplicity". I just don't buy it. If performance is so critical, whatever you gain by moving everything to the database is lost by the fact that databases are harder to scale. You may be able to get by with a sing…
I'm the author. Thanks to Ludwig for posting this here. I've been doing all of my database work like this for 5+ years now, and love it. Many more examples here: https://code.sivers.org/db-api/ It works great when you want to write simple shell scripts, too. They look as simple as this: https://github.com/sivers/store/blob/master/getdb-example.rb... People have been asking how I do unit testing. The main thing is to…
I want to do the same, but with big databases (the TXID wraparound is a problem every few months). For now, the queries are stored in the code. They rarely evolve.
How do you manage versioning? Queries in code mean you can ensure everything match.
How easily other people interact with that? Not many developers know SQL well. Poor SQL skills can slow down a server for other users.
What did you gain in practice? It is nice, like CI/CD or version control, but I see little gains for something that does not change very often.
Currently, most of the queries are materialized views that can be refreshed separately. It seems simpler to me.
In practice, how is this different from refreshing materialized views?
I'm the author. Thanks to Ludwig for posting this here. I've been doing all of my database work like this for 5+ years now, and love it. Many more examples here: https://code.sivers.org/db-api/ It works great when you want to write simple shell scripts, too. They look as simple as this: https://github.com/sivers/store/blob/master/getdb-example.rb... People have been asking how I do unit testing. The main thing is to…
I read this a few days ago. I was waiting for it to show on HN because I have a few questions. I want to do the same, but with big databases (the TXID wraparound is a problem every few months). For now, the queries are stored in the code. They rarely evolve. How do you manage versioning? Queries in code mean you can ensure everything match. How easily other people interact with that? Not many developers know SQL well…
Other people : I guess like anyone choosing a language, you're excluding those who don't know it. I'm assuming more know SQL than Rust or Elixir or whatever. And more should.
Gain in practice : Two best improvements were:
(1) Having all data and data-logic (which might also be business-logic) in the same place. No worrying that some external code somewhere might have old data/business logic in it. One definitive source. Like Rich Hickey's classic "Simple/Complex Hard/Easy" talk - https://www.youtube.com/watch?v=rI8tNMsozo0 - I like that this is simple, un-complex. The data and external code don't need to be braided/complected together to work.
(2) The freedom do switch my external code from Ruby to Go or Elixir or whatever, and not have to rewrite all that functionality. It's all just simple API calls.
Sorry I haven't looked into materialized views yet, so I don't know how this compares.