I ran across Aaron Bertrand's naming post recently, which I liked overall. Your team needs to agree how things are named, and be consistent, but I agree that some of the rules I've seen put down by people aren't practical. However I also know that naming things becomes hard, especially over time as your systems evolve and the scale grows.

I've run into some strange naming patterns in the last few years that struck me as odd. I grew up in the Hampton Roads area of Virginia, and with a parent selling real estate, I traveled all over the area, often reading a map to navigate. I can rarely remember seeing the same names used over and over, despite the fact this was a relatively populous area.

However when I came to Colorado, I found things to be different. Either the people in charge of naming weren't creative, or they were very, very lazy. In some of the developments I entered, I'd find the same name used many times on adjacent streets. You can find Wolfe St, Wolfe Pl, Wolfe Ct, and more all next to each other. While a computer can easily differentiate these sets of characters, this can easily create confusion in humans.

On a note closer to our livelihood, I have seen some strange databases objects. The tables in a JD Edwards system were coded with a short alpha sequence and then a 4 or 5 digit number. Always fun to remember what "FS3401" means. However I saw one recently that stunned me. I ran across a SQL Server database that was quite large, not in data size but in the number of objects. Apparently a developer or DBA at some point decided it wasn't worth trying to name tables to match some entity and used GUIDs are names instead. I don't know about many of you, but comprehending which GUID stores which data might have me resigning from that position relatively quickly.

We won't all necessarily agree on how we should best name objects and entities, and that's fine. However I would implore you to at least consider the humans that will have to work with your database. Use some creativity to build names that are easy to differentiate and pronounce for the future DBAs and developers that need to enhance and query your system.