Results 1 to 7 of 7

Thread: Database Naming

  1. #1
    Join Date
    Dec 2010
    Posts
    39

    Database Naming

    I am working with a customer who will have 1000's of clients. Currently we are planning to move to a 'multi-tenant' database whereas groups of 100 customers will be within a single database with all the ID's and such to discern by customers.

    Until we get there I am trying to get input from others on naming conventions they may of used in the past for single databases where we can have 100's until we get to multi-tenant.

    I was thinking to name releated to State and CustomerID something like
    db_TX_100019 ?

    As I am not expert on MySQL was wondering what others may think, in the long run what would be the best method for naming. I am thinking about the fact that we may take a year or more to get the multi-tenant complete and was thinking about support and such.

    Basically trying to find out the 'best' way from others that may of done this in the past.

    Thanks for reading

    From The Dark Side Of The Moon!

  2. #2
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Short answer: don't use multiple databases. Use a single database.

    Why would you want to split the data up in such a way when you could write queries to show such results instead?
    George
    Home | Blog

  3. #3
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    George, he doesn't want to.
    They're moving to a multi-client db design. He just needs an interim solution.

    Mr. Floyd, your naming convention should suffice, except that you should drop the "db_" prefix. Prefixing database objects with their object type ("tbl" for tables, "vw" for views, etc) is a relic of procedural programming.
    "db_" supplies no information. Obviously, its a database.
    Instead, prefix with the name of the application:
    OurBloatedApp_TX_100019
    I'd also suggest padding the customer number with leading zeros as necessary so that the customer number lengths are all identical. This will make them sort consistently.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  4. #4
    Join Date
    Dec 2010
    Posts
    39
    Thanks for the input. As we have other 'databases' on these servers the db_ prefix would allow sorting by the customers.

    Appreciate the input and thanks to all that read and replied.

  5. #5
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    I don't get

    Where is the data now?

    Where is the data going to go to?
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  6. #6
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Quote Originally Posted by pinkfloyd43 View Post
    Thanks for the input. As we have other 'databases' on these servers the db_ prefix would allow sorting by the customers.

    Appreciate the input and thanks to all that read and replied.
    Uhmm...NO. Adding "db_" to all the database names does not affecting sorting, as they all have the same prefix. And as I pointed out, "db_" contains not informational value. Use the application name instead of "db_".
    Using "db_", or even worse "tbl_" is just noobish.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  7. #7
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    i see people using "tbl_" prefix on table names all the time, and not a single one of those people admits to also using the "col_" prefix on columns

    only once has anyone ever even responded to my suggestion to use "col_", and it was to say "no, that'd be silly" to which i gleefully replied "my point exactly!"

    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •