Feedback #1
Description
Really liked the presentation, especially since it makes a serious attempt at murdering the holy cow called ORM that has plagued too many projects.
Developers everywhere are paying the cost of investing their effort in a mini-language imposed by specific ORM / query-builder (and sometimes a self-inflicted pain of having to use the Model leaky abstraction which causes impedance mismatch) instead of just learning how to write the well-designed, most-portable SQL code.
Here is one point that I found really important:
SQL is the language of the RDBMS
These days, the best way to learn how to work with a RDBMS is through reading their documentation and going over web-indexed solutions to well-known issues written by mostly experts as answers to questions on StackOverflow or blog posts / articles. These are usually written in SQL.
Therefore, when you use an ORM / Query-builder you immediately have to face these problems:
-
Problem 1: You would be wasting time translating between an available, portable SQL solution to a non-SQL, non-portable solution written in an ORM / Query-builder mini-language?
-
Problem 2: Your code is going to be less readable. For the next developer looking at your mini-language code (could be you in a few weeks), it's going to be almost impossible to understand what it's trying to do without making a (lossy!) inverse translation back to SQL and attempting to google that.
Further Reading
- Knex author Tim Griesser explains Knex
- Slonik author Gajus Kuizinas writes about the modern approach he is taking with a driver-level library for PostgreSQL
- Dan Muey presents an overview and a tuorial to Sqitch, a VCS-like db-agnostic migrations CLI tool (recently realeased the milestone 1.0 version!)
- Some example code I've written using the
sqlite3driver for a File Manager app I'm developing in my free time