What ORMs Have Taught Me: Just Learn SQL (2014)
I&#x27;m a Go developer and I notice a lot of other Go developers instantly suggest things like GORM to noobs writing applications. Whereas I always suggest against it.<p>I&#x27;m a big advocate of understand your data model at the database level. Need to join on too many tables is too easy to do with an ORM.<p>My go-to strategy for SQL is simple. Abstract your SQL as far away from your application as possible. Not just by using interfaces in your application, but by using stored procedures in your database.<p>In my mind SQL is just another service your application depends on. And you want that interface to be as simple as possible for your application. If you need to tweak SQL performance it should not need any input from your application. I could completely migrate to a new table relationship structure without the application realising if that was what was needed. You could even go as far as to unit test just your SQL code if you wanted, something you can&#x27;t do too easily when it&#x27;s in your application.<p>Yes, if you need to return new data then you need to update your stored proc and code. But that&#x27;s so worth it in my opinion for that extra layer of abstraction.<p>My opinion is slightly skewed from a decently sized business perspective, but I do still follow this pattern in personal projects. When migrating applications to different tech stacks (like Java to Go, or C# to Go) this abstraction has meant the world to us.