I used to think query builders were GUI apps that allowed you to select tables and make joins graphically while generating SQL under the hood, but now I understand that you also call query builders the APIs that provide a way of not having to create pure SQL queries, so abstracting yourself of potential differences in SQL flavors.

Using such query builders is good, but I tend to think that people who rely heavily on them tend to not ask DBAs: "hey, this is a query I use a lot, please create a view from it".

Don't get me wrong.

I think that you should write queries against views and not tables. Not for security or filtering, which are good reasons, but for the same reason you should code against interfaces and not against concrete classes: decoupling. Views are like "contracts", the same way interfaces are "contracts" in OOP. You can change the underlying tables, but as long as you force the views to show the same "contract" to the programmers, code should not break.

Again, don't get me wrong, you can use query builders to query views, but much views come to exist as a maduration process that is the product of having to write queries and asking your DBA: "man, create this, please".

Am I wrong in thinking that by not writing queries you fail to detect the need of creating certain views?

Another think that concerns me is novice programmers not mastering SQL, one of the most beautiful pieces of technology created by man, by not having to do so.

I used to think query builders were GUI apps that allowed you to select tables and make joins graphically while generating SQL under the hood, but now I understand that you also call query builders the APIs that provide a way of not having to create pure SQL queries, so abstracting yourself of potential differences in SQL flavors.

Using such query builders is good, but I tend to think that people who rely heavily on them tend to not ask DBAs: "hey, this is a query I use a lot, please create a view from it".

Don't get me wrong.

I think that you should write queries against views and not tables. Not for security or filtering, which are good reasons, but for the same reason you should code against interfaces and not against concrete classes: decoupling. Views are like "contracts", the same way interfaces are "contracts" in OOP. You can change the underlying tables, but as long as you force the views to show the same "contract" to the programmers, code should not break.

Again, don't get me wrong, you can use query builders to query views, but much views come to exist as a maduration process that is the product of having to write queries and asking your DBA: "man, create this, please".

Am I wrong in thinking that by not writing queries you fail to detect the need of creating certain views?

Another thing that concerns me is novice programmers not mastering SQL, one of the most beautiful pieces of technology created by man, by not having to do so.