views:

305

answers:

9

I have noticed a lot of companies use a prefix for their database tables. E.g. tables would be named MS_Order, MS_User, etc. Is there a good reason for doing this? The only reason I can think of is to avoid name collision. But does it really happen? Do people run multiple apps in one database? Is there any other reason?

+3  A: 

Personally, I don't see any value in it. In fact, it's a bummer for intellisense-like features because everything begins with MS_. :) The Master agrees with me too.

JP Alioto
A: 

I have never seen a naming collision, as it usually doesn't make sense to put tables from different applications into the same database namespace. If you had some sort of reusable library that could be integrated into different applications, perhaps that might be a reason, but I haven't seen anything like that.

Though, now that I think about it, there are some cheap web hosting providers that only allow users to create a very small number of databases, so it would be possible to run a number of different applications using a single database, so long as the names didn't collide (and such a prefixing convention would certainly help).

Adam Batkin
A: 

Multiple applications using a particular table, correct. Prefixes prevent name collision. Also, it makes it rather simple to backup tables and keep them in the same database, just change the prefix and your backup will be fully functional, etc. Aside from that, it's just good practice.

Zachery Delafosse
+2  A: 

Huge schemas often have many tables with similar, but distinct, purposes. Thus, various "segmented" naming conventions.

Darn, didn't get first post :-)

Roboprog
A: 

Prefixes are a good way to sort out which sql objects are associated with which app when multiple apps dip into the same database.

I have also prefixed sql objects differently within the same app to facilitate easier management of security. i.e. all the objects with admin_ need this security applied and the rest need something else.

Prefixes can be handy for humans, search tools and scripts. If the situation is a simple one, however, there is probably no use for them at all.

HeathenWorld
A: 

It's most often use if several applications are sharing one database. For example, if you install Wordpress, it prefixes all tables with "wp_". This is good if you want your applications to share data very easily(sessions across all applications in your company, for example.)

There are better ways to accomplish this however, and I never prefix my table names, as each application has it's own self-contained database.

Mike Trpcic
A: 

Even when the database only contains one application, the prefixes can be useful in grouping like parts of the application together. So tables that containtain cutomer information might be prefixed with cust_, those that contain warehouse information might be prefixed with inv_ (for inventory), those that contain finacial information might be prefixed with fin_, etc.

HLGEM
+1  A: 

In SQL Server 2005 and above the schema feature eliminates the need for any kind of prefix. A good example of their usage can be found by reading about the Schemas in AdventureWorks.

In some older versions of SQL server, having a prefix to create a pseudo namespace might of been useful with DBs with lots of tables.

Other than that I can't really see the point.

RichardOD
Thanks for the link, that's interesting. Too bad "we" only have 2 schemas: "dbo" and "tempdb" (Sybase uses the same or similar namespace convention, unsurprisingly)
Roboprog
+1  A: 

I've worked on systems where there is an existing database for an application which was created and maintained by a different company and we've needed to add another app that uses large amounts of the same data with just a few extra tables of our own, so in that case having an app specific prefix can help with the separation.

Slightly tangentially to the original question, I've seen databases use prefixes to indicate the type of data that a table is holding. There'd be a prefix for lookup tables which are obviously pretty static in both size and content and a different prefix for the tables that contain variable data. This in turn may be broken into having one prefix for tables that are added to but not really changed like logging, processed orders, customer transactions etc, and and another for more variable data like customer balance or whatever. Link tables could also have their own prefix to separate them out too.

eviltobz