3 ms·
Nice example of: always begin with the end in mind - first specify what data you want to see and then specify where it should come from. I think it helps you f
by ako 5y ago
Nice example of: always begin with the end in mind - first specify what data you want to see and then specify where it should come from.
I think it helps you focus on the outcome required, and makes you more efficient deciding how to implement it.
I use the same approach for methods in normal code: first decide on the signature of the method, and potentially a unit test to test it, and then think about the implementation.
- tehlike 5y agoI like to think of data transformation a chaining problem. Linq lambda syntax is kind of like that. db.Table.where(x=> x.name == 'abc').skip(10).take(20).groupBy() This is really hard in sql especially with temporary tables and nesting you need to do as soon as you need to do things a little out of order... Etc
- ErwinSmout 5y agoThat's because the true foundation is that relational algebra is (a) an algebra and (b) closed over relations. (a) means you should have an expressions system that allows arbitrary nesting and (b) means you should be able to arbitrarily nest relational expressions in particular. SQL fails heavily on (b) (it fails less so than it used to do with the SQL:1992 standard but even so, it's still far from where we should have been and SQL itself is still an abomination). Moreover, your very examples illustrate how "thinking SQL" is *NOT* the path to finding proper solutions. .skip() and .take() clearly originate from the world of ranking problems and it drips off of every word that you were thinking of finding a "modern" way to specify [things like] "TOP 10", but those solutions are themselves a fundamentally crippled way to attack the problem.