Naming Confusion

  • I prefer using suffixes to prefixes. Personal preference, but that's the way I roll.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Conventions are somewhat subjective. I lean towards prefixes for dev, prod etc, and they work well.

    Another thing that works very well is Server Groups within SSMS Registered Servers. I have separate groups for dev, qa, and prod. When I want to connect to a prod server, I know I have to navigate to the prod Server Group first, and that vastly reduces any room for confusion over which environment I am working in. Another thing I find useful, as a practice: always open dev and qa in only the left monitor, and open prod only in the right monitor. It's simple, but very effective.

    Hakim Ali
    www.sqlzen.com

  • I've run into various naming conventions that have caused problems over the years. One of my favorites was naming printers after the 7 Snow White dwarfs. It was a bit limited for growth. I've also seen different conventions for physical vs virtual servers. That went to hell when we went through a big P2V project.

  • Difficult to satisfy everyone with server naming conventions, someone will always have a problem with what you choose! we tend to go for suffixes for dev/test, but the naming of servers is contentious even within our team!

  • I have worked in the IT field (Data Processing when I first started) for a very long time and seen many techniques come and go and come back. (and no I don't remember when Hector was a pup). My early experience was in the UNIX world where we named servers from Lil Rascals, Star Wars, and planets\moons\stars. I found these to be both fun because they were easy to remember and serious since it had one hidden security feature, you could not tell the server's purpose just from the name. In the Windows world, that started to change as the number of Windows servers grew. However, now I am use to the complicated names. But now as a DBA and dealing with SQL and SSMS, I prefer to use the sqlcmd mode then connect only to my local instance. When going to other instances, I use :CONNECT. This keeps things safe on many levels. The only drawback is Intellisense doesn't work, which is fine by me since it is more of an irritant than a help to me. There are pros and cons, most notably, I can query multiple instance in the same pane and compare results easier.

    What ever floats your boat or make your world twirl.

    Akinja Richards

  • Eric M Russell (5/21/2015)


    Executive managment has requested that available MB disk storage (zero padded to 10 digits) be appended to the end of all server names. You know... as a convenience for the users, so they have that information when they connect. It has been suggested that you kick off a nightly job to update the server names enterprise wide and then send email notifications to everyone with database access so they can change their connection strings accordingly. We'll need this deployed by June 1 before you go on vacation. :hehe:

    Prepare three envelopes....

    Our servers are mostly based on the letters of the Greek alphabet: Tau, Kappa, etc. Sometimes they have a number, I'm not sure if it represents the year acquired or the initial version of the OS.

    -----
    [font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]

  • I simply put the type of server (except prod) on the end of the db name and colour code the windows based on the server.

    e.g Sales, Sales_Development, Sales_Testing

    Hard to get confused about that.

  • I too have seen many different conventions, from ancient Greeks on UNIX boxes in college to Japanese novelists at a globalization/localization vendor. I work for a big company, and as applications move to our private cloud, I've noticed non-Windows boxes get cryptic names whereas the Windows boxes have very high-level descriptors of physical/virtual, platform (DB, web, etc.), and environment.

    I don't think it's necessary to include much metadata in a server or instance name, and as others have pointed out, it can get in the way when you have many servers or servers that might move between physical and virtual. However, I've found that having an easily pronounceable label for a server is useful when talking with others. To that end, my group assigns our boxes unofficial aliases that are geographical names without any association with the servers. We also use a table on a wiki page to list our servers, aliases, and a couple of other key pieces of information about each one. If we need further details, we can query various IT groups' inventory databases.

  • My company is required to hide the server's application or purpose. We tend to name them in related groups, comic book characters, cars, amusement parks, etc, and sometimes use suffixes -D,-T,-P for dev/test/prod. We also tend to make the last one in alphabetical order prod and the first one as dev. Since we virtualized our servers, we've found naming servers with location meta data provides no benefit.

  • For business production and Infrastructure production then a role based name with an incrementing ID does. Who cares if there are gaps in the numbers or a reinstall.

    For test/development/proof of concept/UAT/load testing... if I can get away with it the server name is a silly name. Most developers like it unless they are too pretentious, no one mistakes them for live, and everyone also have a sense that the server is not suddenly going to get promoted to live. Also easier to remember when someone comes to me and says "server OXF3523SQL is broken!!" compared to "Muttley is dead!!"

    In some companies that I have worked the infrastructure team looks after all the business servers and leaves all the developers to themselves. Infrastructure teams dont always understand that the development server is the production sever for the developers, and the test server is the production server for the tester.

  • One of my favorites was naming printers after the 7 Snow White dwarfs. It was a bit limited for growth.

    Dwarfs, limited for growth. I see what you did there πŸ™‚


    On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
    β€”Charles Babbage, Passages from the Life of a Philosopher

    How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537

  • BWFC (5/22/2015)


    One of my favorites was naming printers after the 7 Snow White dwarfs. It was a bit limited for growth.

    Dwarfs, limited for growth. I see what you did there πŸ™‚

    Missed that second meaning. Feeling suitable put down πŸ˜€

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • T_Peters (5/21/2015)


    I've run into various naming conventions that have caused problems over the years. One of my favorites was naming printers after the 7 Snow White dwarfs. It was a bit limited for growth. I've also seen different conventions for physical vs virtual servers. That went to hell when we went through a big P2V project.

    Now, when it comes to naming networked printers, I do think that the name should include location along with model.

    For example:

    "ATL_HPLJP400_FL03CR12"

    Atlanta office, HP LaserJet Pro 400 printer, conference room 12 on the 3rd floor.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell (5/22/2015)


    T_Peters (5/21/2015)


    I've run into various naming conventions that have caused problems over the years. One of my favorites was naming printers after the 7 Snow White dwarfs. It was a bit limited for growth. I've also seen different conventions for physical vs virtual servers. That went to hell when we went through a big P2V project.

    Now, when it comes to naming networked printers, I do think that the name should include location along with model.

    For example:

    "ATL_HPLJP400_FL03CR12"

    Atlanta office, HP LaserJet Pro 400 printer, conference room 12 on the 3rd floor.

    And when the printer moves with a team?

    The same problem still applies. Often printers are assigned to teams or departments so move with the team/department. I have seen this occur within the last 12 months.

    STOP WITH THESE VARIANTS OF HUNGARIAN NOTATION!!!1

    It is these codified values that are subject to change which will become outdated and inevitably waste time and cause confusion.

    1 We have gone through this argument with naming in code so why is it not seen for what it is in naming in general. After all, in general, we tend to be great at concepts and abstractions.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Gary Varga (5/22/2015)


    Eric M Russell (5/22/2015)


    T_Peters (5/21/2015)


    I've run into various naming conventions that have caused problems over the years. One of my favorites was naming printers after the 7 Snow White dwarfs. It was a bit limited for growth. I've also seen different conventions for physical vs virtual servers. That went to hell when we went through a big P2V project.

    Now, when it comes to naming networked printers, I do think that the name should include location along with model.

    For example:

    "ATL_HPLJP400_FL03CR12"

    Atlanta office, HP LaserJet Pro 400 printer, conference room 12 on the 3rd floor.

    And when the printer moves with a team?

    The same problem still applies. Often printers are assigned to teams or departments so move with the team/department. I have seen this occur within the last 12 months.

    STOP WITH THESE VARIANTS OF HUNGARIAN NOTATION!!!1

    It is these codified values that are subject to change which will become outdated and inevitably waste time and cause confusion.

    1 We have gone through this argument with naming in code so why is it not seen for what it is in naming in general. After all, in general, we tend to be great at concepts and abstractions.

    Agree!



    Alvin Ramard
    Memphis PASS Chapter[/url]

    All my SSC forum answers come with a money back guarantee. If you didn't like the answer then I'll gladly refund what you paid for it.

    For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]

Viewing 15 posts - 31 through 45 (of 52 total)

You must be logged in to reply to this topic. Login to reply