Facts are facts. What you have pointed out here is that words can have different meanings (very true) and that a fallacy is not a fact (also true).
I will agree that it is the case that certain facts as we know them today may cease to be facts in the future. For example, it was once believe to be a fact that the Sun revolved around the Earth.
Great question. I suppose that is why people just feel the need to consume more...because they don't know how much they need.
With food it is easier to measure a proper intake. That's not the same with data. As a result, business will always want more. Most internal IT departments won't be able to keep up over time. As a result, the business looks outside.
So, if you are clinging to the idea that there will always be a need for a traditional DBA, you are wrong. Our roles are changing, right before our eyes.
I think there is a special level of hell for people who use nested views across linked servers hundreds of miles apart and demand that the DBA team give them sub-second response times despite limitations put upon them by things like the speed of light.
...or, I could use "mvw" to designate a new type of object...
I agree, the client shouldn't care about the data being a table or a view. But as a DBA, if I need to quickly find a solution to a problem, the use of a prefix can be a benefit.
There are costs and risks for all design choices. If you are working with a system that is growing and prone to the need of denormalizing frequently then perhaps using a prefix isn't the right choice.
But not every system has that issue. I see more cases these days of smaller databases...think "one database per customer" type of architecture. Denormalization isn't an issue often, and prefixes seem to work just fine.
Only when you don't use prefixes that are somewhat standard.
At the end of the day, however, consistency is key. For example, you used a capital letter to distinguish the start of a word, making it easier for me to understand what you were saying.
Let's say you have identified a performance problem on a single page of a web application that lists results from a query.
Let's say you look at the code and see a complex query.
What do you do?
You use the equivalent of EXPLAIN on your DB.
It should be pretty clear at that point what objects you are dealing with.
The point of a view is that it should be interchangeable with a table logically. There are many cases I've been involved in where a view was used to either temporarily address a performance issue or address a data migration need.
If you have a naming standard that requires objects to be named a certain way, you're going to have to do a code push along with a database change that would otherwise only require a database change. That's a lot of extra testing and a lot of extra risk.
Either that or you are going to temporarily break your own rules just for that one thing. But now guess what, you've created an even bigger problem because you have trained everyone to not look at the EXPLAIN plan and instead rely on the names of the objects, and so now they'll be really confused because you've temporarily made a view "look" like a table.
In practice, this is a solution to a non-issue. YMMV.
This is the same as the "don't use aliases but instead tablename_id for Id fields because at 3am this will help you" type of argument (a real one, unfortunately) you should not model things around exceptions.
Absolutely, but there are also times when you can't touch code. For example: Sharepoint. Lots of vendors tell you to keep your hands off their code. When that happens, you may be forced to take action.
I will agree that it is the case that certain facts as we know them today may cease to be facts in the future. For example, it was once believe to be a fact that the Sun revolved around the Earth.
Thanks for reading!