What is the purpose of tbl_Product, tbl_Order rules?

Question

I saw tbl_ prefixes decorating all the tables in the last two base codes that I worked with. I cannot think of why they would be useful for application developers or database administrators.

If the database administrator needs to see which objects are tables, can they always join the DMV or schema tables in the correct order? I cannot think how they will be useful to the programmer, especially if the project uses the ORM tool.

However, even when recording stored procedures, they simply interfere.

Can someone explain how they will be useful not subjectively? Ex (with tbl_ helps me complete task x)

Answer 1

I have heard the same thing over and over again because it helps them know the type of object.

Within a query, using prefixes can help, for example, separate tables from views .

I really disagree with that. After getting used to the database schema, the prefixes become redundant and, as with all redundancy, can become desynchronized or make changes more difficult.

Suppose you have a table, for some reason you need to split into two tables. Suppose you decide to create a view that emulates a source table that selects data from two new tables.

Are you going to rename your entire code base, or are you going to stick with the view preceded by tbl _?

So, my point is the names of the database objects, there are no prefixes to output their types.

Answer 2

I can not think of many advantages. You can definitely see cleaner SQL as follows:

select post.id, post.subject, post.body from tbl_post post where post.author="eric" 

Makes your variables easier. Otherwise, it looks like you are dealing with people who have studied databases in MS Access.

Answer 3

This is a Hungarian notation, or rather misuse. Initial use was associated with some important aspects of using a variable as a prefix. The fact that a table is a table is hardly a useful way to use Hungarian notation.

In ASP, Hungarian notation is used to indicate the data type, since VBSCript has only options. I have seen ASP programmers apply this to tables and fields in a database, this is one way to exploit this misuse.

Answer 4

one of the advantages is that you can tell the difference between a view, a table, and a materialized view. Of course, it does not really matter when you write code, this is important. If someone realizes that they are leaving the view, they can better optimize the code. Views based on views based on views can be very inefficient. Without the tbl_ or view_ prefix, it can be harder to tell if this is happening.

Answer 5

I think that when using ORMs such as the Entiry Framework, it might be easier to determine which side this relation relates to tables and which side deals with objects (entities). For example, my tbl_Employee maps to Employee . Unable to confuse layers of abstraction.