tbl_Product、tbl_Order 命名约定的目的是什么？
我已经看到 tbl_ 前缀装饰了我使用的最后两个代码库中的所有表。 我想不出它们对应用程序开发人员或数据库管理员有用的任何原因。
如果 DBA 需要查看哪些对象是表，他们总是可以连接到 DMV 或 master 中的模式表，对吗？ 我也无法想象它们对程序员有何用处，如果项目使用 ORM 工具则更是如此。
即使在编写存储过程时，它们似乎也只是妨碍。
有人能以非主观的方式解释它们如何有用吗？ 例如（拥有 tbl_ 可以帮助我执行 x 任务）
I've seen tbl_ prefixes decorating all tables in the last two code bases I've worked with. I can't think of any reason they'd be useful for application developers or database administrators.
If a DBA needs to see what objects are tables they can always join up to DMV's or the schema tables in master right? I can't think of how they'd be useful to a programmer either, even more so if the project is using an ORM tool.
Still even while writing stored procs they just seem to get in the way.
Can anybody explain how they'd be useful in a non-subjective way? Ex ( having tbl_ helps me perform x task )
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我一遍又一遍地听到同样的事情，原因是，它可以帮助他们了解对象的类型。
在查询中，使用前缀可以帮助他们将表与视图分开。
我真的不同意这一点。在习惯了数据库模式之后，前缀变得多余，并且与所有冗余的情况一样，它可能会变得不同步或使更改变得更加困难。
假设您有一个表，无论出于何种原因，您都必须将其拆分为两个表。
假设您决定创建一个视图来模拟原始表，并从两个新表中选择数据。
您要重命名整个代码库还是要坚持使用前缀为 tbl_ 的视图？
所以我的观点是数据库对象名称不应该有任何前缀来推断其类型。
I’ve heard the same thing over and over again the reason being, it helps them to know the type of the object.
Inside a query, using prefixes could help them separate tables from views for instance.
I really don’t agree with that. After getting used to the database schema, prefixes become redundant and as happens with everything that is redundant, it can become desynchronized or make changes harder to do.
Let’s say you have a table that for whatever reason you have to split into two tables.
Let’s say you decide to create a view that emulates the original table selecting data from the two new tables.
Are you going to rename throughout you code base or are you going to stick with a view prefixed as tbl_?
So my point is database object names should not have any prefixes for inferring their types.
我想不出有多少好处。 您肯定会看到像这样更干净的 SQL：
让您的变量更容易。 否则，这看起来就像您一直在与在 MS Access 上学习数据库的人打交道。
I can't think of many benefits. You could definitely see cleaner SQL like this:
Makes your variables easier. Otherwise, this just looks like you've been dealing with people who learned databases on MS Access.
这是匈牙利表示法，或者更确切地说是对它的误用。 最初的用途是把变量使用的一些重要方面作为前缀。 表格就是表格这一事实很难说是使用匈牙利表示法的有用方法。
在 ASP 中，匈牙利表示法用于指定数据类型，因为 VBSCript 只有变体。 我见过 ASP 程序员也将其应用于数据库中的表和字段，这是这种滥用的一种方式。
This is hungarian notation, or rather a misuse of it. The original use was to put some important aspect of the use of 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 specify a data type, as VBSCript only has variants. I've seen ASP programmers apply this to tables and fields in the data base too, that is one way that this misuse come into use.
它的好处之一是您可以区分视图、表和物化视图之间的区别。 当然，当你编写代码时这并不重要，重要的是维护它。 如果有人意识到他们正在从视图中提取数据，他们也许能够更好地优化代码。 基于视图的视图可能非常低效。 如果没有 tbl_ 或 view_ 前缀，可能更难判断是否发生这种情况。
the one benefit of it is that you can tell the difference between view, table, and materialized view. Of course, this doesn't really matter when you are writing the code, it is maintaining it that matters. If someone realizes that they are pulling from a view, they might be able to optimize the code better. Views based on views based on views can be very inefficient. Without the tbl_ or view_ prefix, it might be more difficult to tell if this is happening.
我认为，当使用像 Entiry Framework 这样的 ORM 时，可以更容易地判断映射的哪一侧正在处理表以及哪一侧正在处理对象（实体）。例如，我的
tbl_Employee映射到Employee。没有办法混淆抽象层。I think that when using an ORM such as Entiry Framework, it may make it easier to tell which side the the mapping is dealing with tables and which side is dealing with objects (entities). My
tbl_Employeemaps toEmployee, for example. There is no way to get the layers of abstaction confused.