4 ms·

The trade-off is that of every higher-level VS lower-level anything when it comes to computers: Higher-level: Dependent on the quality of the "bridge", but gen

The trade-off is that of every higher-level VS lower-level anything when it comes to computers: Higher-level: Dependent on the quality of the "bridge", but generally you will benefit from good-practice security measures, less repetition and more idiomatic code with regard to your language of choice. What you lose is the cost of the bridge and the fact that the bridge itself has to be maintained over time, requiring you to keep up with any API changes. Lower-level: Generally less approachable for beginners, highly dependent on your capacity to understand all the implications of the choices you will make, will yield more performance if used correctly because the layer between you and the system is smaller but with power comes responsability.

drinchev 9y ago
> good-practice security measures +1 for that. Even for super small projects, I use an ORM, because there is always some user input that needs to go to the database query string. Life is too short to maintain every single query.
- pllbnk 9y ago
  I would like to add that this is not a binary choice. Depending on the complexity of the requirements its possible to differentiate between and even mix the levels of abstraction. I personally like to avoid using ORM by its true meaning (mapping object and relational models) but I like using certain facilities an ORM library might provide, such as session management, user input validation, etc.
lukaseder 9y ago
The biggest fallacy in this particular debate is the idea that ORMs are somewhat "higher level" whereas SQL is "lower level". SQL is a 4GL, and as such, a much more higher level language than anything you can do with an ORM, which leads to much more "lower level", imperative data interaction patterns. On the other hand, a lot of people put their database in lower layers often confused with or used as synonym for levels. So, the level-ness depends on what you're trying to abstract. Algorithms? SQL will be higher level. Layers? ORMs will be higher level.

drinchev 9y ago

> good-practice security measures +1 for that. Even for super small projects, I use an ORM, because there is always some user input that needs to go to the database query string. Life is too short to maintain every single query.

pllbnk 9y ago
I would like to add that this is not a binary choice. Depending on the complexity of the requirements its possible to differentiate between and even mix the levels of abstraction. I personally like to avoid using ORM by its true meaning (mapping object and relational models) but I like using certain facilities an ORM library might provide, such as session management, user input validation, etc.

lukaseder 9y ago

The biggest fallacy in this particular debate is the idea that ORMs are somewhat "higher level" whereas SQL is "lower level". SQL is a 4GL, and as such, a much more higher level language than anything you can do with an ORM, which leads to much more "lower level", imperative data interaction patterns. On the other hand, a lot of people put their database in lower layers often confused with or used as synonym for levels. So, the level-ness depends on what you're trying to abstract. Algorithms? SQL will be higher level. Layers? ORMs will be higher level.