SQLRockstar
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!
An Audible Data Privacy Breach
It's That time of year again: Reorg Season
Hootsuite Can Pay Me $5.99 A Month To Stop Reading This
7 Mistakes You Can't Afford To Make When Upgrading To SQL2012
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.
Metadata Stuffing: Why I Hate tbl_ For Table Names
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.
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.
The tools have been failing us. Using a prefix is a way to get around those failings.