Should we use prefixes in our database table naming conventions? Should we use prefixes in our database table naming conventions? database database

Should we use prefixes in our database table naming conventions?


I find hungarian DB object prefixes to indicate their types rather annoying.

I've worked in places where every table name had to start with "tbl". In every case, the naming convention ended up eventually causing much pain when someone needed to make an otherwise minor change.

For example, if your convention is that tables start with "tbl" and views start with "v", thn what's the right thing to do when you decide to replace a table with some other things on the backend and provide a view for compatibility or even as the preferred interface? We ended up having views that started with "tbl".


I prefer prefixing tables and other database objects with a short name of the application or solution.

This helps in two potential situations which spring to mind:

  1. You are less likely to get naming conflicts if you opt to use any third-party framework components which require tables in your application database (e.g. asp net membership provider).

  2. If you are developing solutions for customers, they may be limited to a single database (especially if they are paying for external hosting), requiring them to store the database objects for multiple applications in a single database.


I don't see how any naming convention can improve security...

If an intruder have access to the database (with harmful permissions), they will certainly have permissions to list table names and select to see what they're used for.

But I think that truly confusing table names might indirectly worsen security. It would make further development hard, thus reducing the chance security issues will be fixed, or it could even hide potential issues:

If a table named (for instance) 'sro235onsg43oij5' is full of randomly named coloumns with random strings and numbers, a new developer might just think it's random test data (unless he touches the code that interact with it), but if it was named 'userpasswords' or similar any developer who looks at the table would perhaps be shocked that the passwords is stored in plaintext.