Databases are the endgame for data-oriented design
spacetimedb.com
Databases are the endgame for data-oriented design
1–10 of 157 posts
Re: Databases are the endgame for data-oriented design
#2If the site designers are on here by chance, take a look on iPhone. The blog post is quite squished there, pretty much unreadable.
EDIT: nevermind, fixed after a refresh ¯\_(ツ)_/¯ still maybe worth a look
Re: Databases are the endgame for data-oriented design
#3Thank you, I enjoyed this post.
I am thinking that iteration is just traversal and traversal is just execution.
Take iterators in C++ or standard library "algorithms" library in C++. Or iterators in Rust or in Java.
You just want to traverse and collect values (and calls on functions in some interleaving), which is like joining tables as this article says.
I'm thinking that the definition of the traversal (such as Kafka pipeline, clojure threading syntax, Clojure data driven design, Javascript lodash pipeline) can be mapped to tuples and then the computer can optimise arbitrary chains of traversals based on the number of potential tuples are available and what traversals are equivalent paths or routes to the same traversal.
In other words, every program is a compiler pipeline or database query pipeline.
Maybe Prolog and Datalog can help here. Optimisation of arbitrary traversals and determination of identical traversals.
Or monads are just ordered traversals and OCaml compilers are just traversals of execution (function application) and relationship following, which are joins.
The relational model is everywhere.
Re: Databases are the endgame for data-oriented design
#4My colleagues hate me, but I also found that SQL is The way to write business logic.
Lots of caveats about difficulty to test and weird syntax.
But it is just that SQL is the most terse and standard way so express logic.
And that in itself is the most important factor to avoid bugs. Not what testing strategy you choose.
Re: Databases are the endgame for data-oriented design
#5My colleagues hate me, but I also found that SQL is The way to write business logic. Lots of caveats about difficulty to test and weird syntax. But it is just that SQL is the most terse and standard way so express logic. And that in itself is the most important factor to avoid bugs. Not what testing strategy you choose.
I feel like you've come to the right conclusion, but partly for the wrong reasons. Terseness in and of itself is not useful per se. Code golfing languages are the tersest there is, but we don't write code that way.
Re: Databases are the endgame for data-oriented design
#6My colleagues hate me, but I also found that SQL is The way to write business logic. Lots of caveats about difficulty to test and weird syntax. But it is just that SQL is the most terse and standard way so express logic. And that in itself is the most important factor to avoid bugs. Not what testing strategy you choose.
> And that in itself is the most important factor to avoid bugs.
I'm not sure about that. SQL was the first language I learned and the language that has always been there throughout the decades, and is also where I make the most mistakes.
Re: Databases are the endgame for data-oriented design
#7If the site designers are on here by chance, take a look on iPhone. The blog post is quite squished there, pretty much unreadable. EDIT: nevermind, fixed after a refresh ¯\_(ツ)_/¯ still maybe worth a look
I am on here. Will definitely take a look!
Re: Databases are the endgame for data-oriented design
#8Thank you, I enjoyed this post. I am thinking that iteration is just traversal and traversal is just execution. Take iterators in C++ or standard library "algorithms" library in C++. Or iterators in Rust or in Java. You just want to traverse and collect values (and calls on functions in some interleaving), which is like joining tables as this article says. I'm thinking that the definition of the traversal (such as Ka…
> In other words, every program is a compiler pipeline or database query pipeline.
> Or monads are just ordered traversals and OCaml compilers are just traversals of execution (function application) and relationship following, which are joins.
> The relational model is everywhere.
This is interesting - could you elaborate a bit more?
Re: Databases are the endgame for data-oriented design
#9My colleagues hate me, but I also found that SQL is The way to write business logic. Lots of caveats about difficulty to test and weird syntax. But it is just that SQL is the most terse and standard way so express logic. And that in itself is the most important factor to avoid bugs. Not what testing strategy you choose.
I completely agree!
Transaction-safety is also sublime for business logic.
Re: Databases are the endgame for data-oriented design
#10My colleagues hate me, but I also found that SQL is The way to write business logic. Lots of caveats about difficulty to test and weird syntax. But it is just that SQL is the most terse and standard way so express logic. And that in itself is the most important factor to avoid bugs. Not what testing strategy you choose.
that's how you end up with multi-thousand LOC sql files that contain all the historical business logic and edge cases of a company and it just keeps being piled up on and its complexity keeps growing because not everything is expressible in SQL. So you end up having a big monster that someone needs to support and one that's not very testable easily