For what it's worth. I like to call out views in the naming.
I'll typically use a "vw_" prefix prior to a name which would be similar to table naming. "v_" is also an option, but I also write a lot of DB functions and stored procedures and with all the types, tables, and column names that get used, indicating variables and parameters can be helpful... so "v_" indicates a variable name in the function context which is why views get "vw_".
Mid-range one-liners don't really make convincing arguments, though do they? I appreciate this comment may have been made more in service of a certain smugness and self-satisfaction rather than any real or concrete complaint... but you do you.
On the flip side... perhaps using techniques from the 80s with a programming language and paradigm also from the 80s... and that hasn't changed all that much... isn't all that crazy.
At the end of the day: the evaluation of a given technique such as I described, should be measured against if it makes the development experience simpler and more comprehensible. Being able to instantly tell if a given reference in a procedural query comes from a table a view, a variable, or a parameter, I find helpful since we're typically using many names from these different origins and contexts and frequently side-by-side, such as in a complex query driving the procedural code.
Of course, If you don't like that, or simply don't find it sufficiently "modern" or "fashionable" (my God, what might others think!?)... again, I invite you to do you.
> But definitely not within database functions and procedures.
I generally find Hungarian notation silly, however, there's a compelling argument to have them in functions and procedures — perhaps more than for views. The type of the variable matters just as much as where/how it was declared, such as in/out params.
That's the 'steelman' argument for them, as I understand it.
Ah, naming things. Something about one of the hard problems in computer science...
I think consistency is more important than perfection. If you use something like vw_ as recommended in the sibling comment, that's fine, then try to apply it to all views. (Without being overly strict; sometimes there are good reasons to defy conventions. They're conventions, not laws!)
Just keep in mind that a view is both code and a data contract just like a table definition is. All the usual best practices around versioning, automated deployments, and smooth upgrade paths apply. As soon as an application or downstream view, function, etc relies on that view, changing it risks disruption or breakage. Loud breakage if you're lucky, silent data corruption if you're not!
