5 ms·
The last bit of the article reminds me of an experience I had recently working w/ another group of developers. They write in C# w/ Entity Framework, but they ju
by drbawb 6y ago
The last bit of the article reminds me of an experience I had recently working w/ another group of developers. They write in C# w/ Entity Framework, but they just use it to map stored procedures to C# data-types. All queries to their database go through a stored procedure w/o exception.
They push as much of the business logic as possible to the database. Their reasoning being that if the client insists on a separation between the DB & application servers: you should do as much computation as close to the data as possible. Then just send the end result over the wire.
Due to my own ORM-induced brain damage I found it hard to wrap my head around this at first: a data type in the application no longer represented a table, but the result of a query. Once you realize the database is just another API though it clicks really nicely into your architecture.
I think I still prefer things like Linq, jOOq, Arel, Ecto, etc. where you can write the query in your programming language and have it translated to SQL. It's just nice to see your query right next to the code when debugging. The author is absolutely right though you still have to know SQL to use tools like that effectively, so you might as well just learn it early instead of wasting effort learning the quirks of a specific ORM.
- deepstack 6y agoMost programmer has problem with SQL because it is declarative langue, and doesn't fit into the C, Java context very well. However, if you just spend some time getting use to declarative langue, you will find SQL is quite nice. You just ask for stuff you are looking for and the computer will give to you. And SQL servers like Postgres has gotten so optimised in returning search results, it really out performs mapReduce.
- drbawb 6y agoYup that has been my experience as well - if you read someone's stored procedure it's pretty easy to tell if they're a "relational thinker" or an "imperative thinker." People who embrace an RDBMS will tend to use constructs like CTEs, windows/partitions, set operations, they'll do their conditionals in the projection (i.e w/ CASE statements), they might use a CROSS APPLY to do a transform over a "collection", etc. Whereas people who are "imperative thinkers," who just treat the database like a giant excel spreadsheet, will use flow control for branches, cursors for iteration, tons of temporary variables, etc. Without fail the iterative thinkers wonder why they need monster CPUs for their DB server and it's always pegging one core. Well of course the query planner can't optimize your code: you told it how to get the data, rather than asking for what data you wanted.
- Illniyar 6y agoThis was a fairly common approach about 10-15 years back. It has its charms but it mostly fell out of favor because of versioning. It's very hard to manage multiple versions and migrations for the database and it had a negative affect on development velocity.