3 ms·

Wrong. Relational databases are one of the fundamental components of most large scale applications and SQL is usually the interface. If you are going to be a

by russell 15y ago

Wrong. Relational databases are one of the fundamental components of most large scale applications and SQL is usually the interface. If you are going to be a journeyman or master programmer in this area you must understand it. If you dont, you are just an apprentice. Just like you must understand networking, concurrency, algorithms, data structures, and hardware. If all you understand is Java an its brand of OO then you are a trade school mechanic. I know this is snarky as hell and I apologize for being offensive. But I am not an MIT CS graduate. I am completely self taught. SQL has been a necessary skill in every job I've had in the last 20 years. So when users were complaining were complaining that a data download to csv files was limited to 200 records (due to a dozen joined tables, lazy loading, table locking, using velocity to generate csv files, etc), I threw out Hibernate and velocity and used SQL, JDBC, and direct HTTP output to generate 50 times the output in one tenth the time.

escoz 15y ago
Just because you have an example of a probably poorly designed, over-engineered system that could be completely replaced with some hand written SQL code, doesn't mean that is the best solution for everything. Come back when you have an example of a system running on top of 500 tables, doing read-writes in a big iron server, communicating with dozens of other servers, that uses distributed caching to improve performance, and that you can explain how you can replace an ORM with SQL.
- russell 15y ago
  My point was not that ORMs are bad, but that SQL is required knowledge to communicate with a databases, including getting around the problems an ORM causes. It is hard for me to believe that someone who doesnt understand SQL can be a competent ORM programmer. The system I mentioned was well designed with hundreds of tables, multiple replicated database servers, dozens of web servers, caching and all that. The problem was a specific case where knowledge of SQL was able to produce a 50x performance improvement. I think SQL essential to learn because it bends your mind. You have to think in terms of sets instead of sequential processes. Just like functional programming and BNF are mind stretching.
  - escoz 15y ago
    cool, we agree on that.
Ingaz 15y ago
I'm doing something similar. We migrating billing system with Hibernated business logic into pure SQL.

by russell 15y ago

escoz 15y ago

Just because you have an example of a probably poorly designed, over-engineered system that could be completely replaced with some hand written SQL code, doesn't mean that is the best solution for everything. Come back when you have an example of a system running on top of 500 tables, doing read-writes in a big iron server, communicating with dozens of other servers, that uses distributed caching to improve performance, and that you can explain how you can replace an ORM with SQL.

russell 15y ago
My point was not that ORMs are bad, but that SQL is required knowledge to communicate with a databases, including getting around the problems an ORM causes. It is hard for me to believe that someone who doesnt understand SQL can be a competent ORM programmer. The system I mentioned was well designed with hundreds of tables, multiple replicated database servers, dozens of web servers, caching and all that. The problem was a specific case where knowledge of SQL was able to produce a 50x performance improvement. I think SQL essential to learn because it bends your mind. You have to think in terms of sets instead of sequential processes. Just like functional programming and BNF are mind stretching.
- escoz 15y ago
  cool, we agree on that.

Ingaz 15y ago

I'm doing something similar. We migrating billing system with Hibernated business logic into pure SQL.