Database Naming

  • Hi All,

    I'm trying to come up with a name for a database and I'm stumped. This database is going to be the repository for a bunch of small applications that interact with our main POS system. I need a name that's genericized, but still makes sense. It's currently named AddIn, but I know our creative members can help me come up with a better one.

    Thanks!

    Ruprecht

  • Wow it is pretty hard to name your database. 😛 Nobody on this side of the screen knows your process, projects etc. Maybe PosExt or something.

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • That's exactly the problem I'm having. We don't know what all of these applications are going to be and they might not always be related to our POS system. It's just going to be a cornucopia of small sets of tables related to application extensions and add-ins. And while Cornucopia might be fun, it probably won't fly. 😉

  • How about APP or COMMON or Consolidated.. Without know anything its a shot in the dark..

    CEWII

  • If the schema (I presume that is what you are going to be using) are not related perhaps they should not be in the same database. What if you need to restore one of them to a point in time but not the others?

    Call it POSAPPS, and if something comes along not related, create a different database, this isn't oracle!

    ---------------------------------------------------------------------

  • We're not too worried about restoring since these are only going to be small sets of tables (1-5 tops). I'm hesitant to create individual databases containing only a couple of tables because we log ship everything off-site and it would be more trouble than it's worth.

    Thanks for all of your suggestions, I appreciate it!

  • Ruprecht (10/21/2011)


    I'm trying to come up with a name for a database and I'm stumped. This database is going to be the repository for a bunch of small applications that interact with our main POS system. I need a name that's genericized, but still makes sense. It's currently named AddIn, but I know our creative members can help me come up with a better one.

    How about TDAD which - internally - stands for "The Damn Auxiliary Database"? 😀

    _____________________________________
    Pablo (Paul) Berzukov

    Author of Understanding Database Administration available at Amazon and other bookstores.

    Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
  • Currently named Addln which makes me think of Aladin. Since you don't know what is going to be in the database, Aladin makes me think of a genie in a bottle. So, rub the database and see which app you get. Name the database GENIE (Generic Entity Nameless In Existence).

    How about Pandora (No, not for Avatar). For trying to plan a database and not know what will actually go in it, might lead to a Pandora's Box! You know it's just going to be trouble in the future.

    That's all I got for now.

    ______________________________________________________________________________________________
    Forum posting etiquette.[/url] Get your answers faster.

  • If it's going to be generic "stuff" that's not necessarily related to the other objects in there, does it really matter what you call it? Call it Spanky or Algonquin or Fred and come up with some snappy acronym that matches: Free Relational Application Database. "Hey, let's stick that table in FRED!"

  • Ruprecht (10/21/2011)


    That's exactly the problem I'm having. We don't know what all of these applications are going to be and they might not always be related to our POS system. It's just going to be a cornucopia of small sets of tables related to application extensions and add-ins. And while Cornucopia might be fun, it probably won't fly. 😉

    Well, if the database is to contain only tables related to your POS system(s), then POS is straightforward. Certainly everyone in the organzation is familiar with the term.

    If this database in intended to contain transactional tables for applications across your entire organization, then perhaps ODS would be a proper name. However, first google the term "operational data store" and decide if that's what this database is intended to be. If so, then there are design considerations to take into account that go beyond just what it's named.

    In either case, you may want to consider containing tables related to each specific application under different schema names.

    For example: POS.Intentory.inv_master

    However, reading what you've described above, it's possible that this database will primarily contain metadata tables (reference, lookup, etc.) shared across multiple applications. Perhaps METADATA would be appropriate.

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

Viewing 10 posts - 1 through 9 (of 9 total)

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