If I'm not mistaken then, they sound like assigning a method name to an SQL function that was built previously.
Am I close?
Yes, you're getting close. I'll try to write some pseudo code so you can understand better:
// creating a view
paid_orders_view = SELECT * FROM orders WHERE status = 'PAID';
// using this view
SELECT SUM(subtotal) FROM paid_orders_view;
Not assigning a function, but a SQL statement. In most cases a query.
Why not have this logic stored in the program itself, even as a simple string variable? What am I gaining from using this functionality?
Not challenging, 100% curious.
One nice thing about a function stored in SQL is that SQL can create an "execution plan" and store it as well, so it doesn't have to reparse and plan everything each time you submit the query. It speeds things up, especially with queries you use frequently.
For me, views often are kind of abstractions or interfaces. Especially when the view contains joins. It hides the details of the data model. Database programmers can even change those details while maintaining the SELECT clause of the view so for the application programmer the interface has not changed.
SQL views aren't just stored queries, it's a virtual table. You can make joins and select specific columns, granting permissions to different database users to it, instead of granting permission to every table. Views are also indexed, when talking about materialized views.
So by using SQL views you've got: security, performance and simplicity. Also, not every system is backed by a modern application layer.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.