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_".
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!
sbuttgereit|1 year ago
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_".
cwbriscoe|1 year ago
Kwpolska|1 year ago
drunkpotato|1 year ago
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!