3 ms·

Indeed, ORM is encouraged out of the box in many ecosystems... and sure enough, it is viewed as a silver bullet by many developers and this is a pity. Some ORM

by henvic 7y ago

Indeed, ORM is encouraged out of the box in many ecosystems... and sure enough, it is viewed as a silver bullet by many developers and this is a pity. Some ORMs are powerful and even have subsets of language for data transformation, and so on... And now you have even another problem: another layer of abstraction that might fail or have their own bugs and security issues. I miss writing pure and simple SQL queries whenever I'm forced to use an ORM. This is one of the things I enjoy in the Go ecosystem: if you want SQL, probably go with database/sql and write SQL directly instead of any fancy ORMs out there.

6thaccount2 7y ago
I don't write anything user facing, but write plenty of scripts that query a database, return a dataset, create a data frame, and then do statistical analysis on it. The SQL is all pretty straightforward with no ORM and is really easy to understand and use.
- henvic 7y ago
  Yeah. Most of the time I see people complaining about SQL, I identify that they are trying to build complex nested joins and other stuff likewise for no good reason besides risky premature optimization... And they end up creating little monsters that will haunt them sometime in the future. Then, what happens next? They might end up hating SQL for no good reason and embracing the 'NoSQL' flag with any kind of non-relational database out there and make the very same mistakes they were complaining about SQL, only this time it'll be probably in JSON instead. And they will probably notice earlier the errors and end up thinking SQL is harder and, say, whatever-NoSQL-brand is easy... only because they had more experience and a clear vision of everything when trying out the later. I just wished more people would just keep things simple. For most common web applications out there a single SQL database suffices well, and you can do most, if not all, queries on two or three lines at most with no complex operations and keep things lean. For sure, for search engine ElasticSearch is marvelous, and for keeping track of documents without ever losing data, Datomic is a robust and proven solution... but what I see is mostly people writing software for mom-and-pops shops using Mongo with no transaction support whatsoever.

by henvic 7y ago

6thaccount2 7y ago

I don't write anything user facing, but write plenty of scripts that query a database, return a dataset, create a data frame, and then do statistical analysis on it. The SQL is all pretty straightforward with no ORM and is really easy to understand and use.

henvic 7y ago
Yeah. Most of the time I see people complaining about SQL, I identify that they are trying to build complex nested joins and other stuff likewise for no good reason besides risky premature optimization... And they end up creating little monsters that will haunt them sometime in the future. Then, what happens next? They might end up hating SQL for no good reason and embracing the 'NoSQL' flag with any kind of non-relational database out there and make the very same mistakes they were complaining about SQL, only this time it'll be probably in JSON instead. And they will probably notice earlier the errors and end up thinking SQL is harder and, say, whatever-NoSQL-brand is easy... only because they had more experience and a clear vision of everything when trying out the later. I just wished more people would just keep things simple. For most common web applications out there a single SQL database suffices well, and you can do most, if not all, queries on two or three lines at most with no complex operations and keep things lean. For sure, for search engine ElasticSearch is marvelous, and for keeping track of documents without ever losing data, Datomic is a robust and proven solution... but what I see is mostly people writing software for mom-and-pops shops using Mongo with no transaction support whatsoever.