合格命名
我目前正在对一个应用程序进行一些维护，并且遇到了有关 tsql 中限定名称的大问题。我想知道是否有人可以帮我消除我的困惑。
据我了解，您希望使用 USE [DatabaseName] 来声明您正在使用哪个数据库。我注意到，如果您“重命名”数据库，它会自动更新代码中的这些引用。
但是，最初编写此代码的开发人员使用了 USE [DatabaseName]。然后在后面的语句中他写道：SELECT * FROM [DatabaseName].[dbo].[Table]。如果我更改数据库的名称，这显然会中断。根据我的阅读，您只想将名称限定为所有者，例如：[dbo].[TableName]，这样它就知道在哪里查找可以提高性能。
他在每个语句中包含数据库名称是否有原因？
I'm currently doing some maintenance on an application and I've come across a big issue regarding the qualified name in tsql. I wondering if someone could clear my confusion up for me.
From my understanding you want to use USE [DatabaseName] to declare which database you are using. I notice if u "rename" the databse it automatically updates these references in your code.
However, the developer who originally wrote this code used the USE [DatabaseName]. Then in later statements he wrote: SELECT * FROM [DatabaseName].[dbo].[Table]. Well this obviously breaks if I change the Database's name. From what i've read you want to qualify names only to the owner such as: [dbo].[TableName] so it knows where to look which increases performance.
Is there a reason he included the Database name in each statement?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不知道，但看起来有人很懒。
我总是使用三个名称格式（除非访问链接服务器实例，则为四个）。
好处是来自正确数据库的正确表&将使用架构，而不用担心错误的
USE [适当的数据库]语句。只要对象存在，并且权限根据需要有效，您就可以在其他数据库中重新创建存储过程、函数、视图等，而无需使用USE [适当的数据库]语句每次。但我正在处理分布在同一实例上的多个数据库中的数据。我不一定会那样设计，但不会改变我使用三（或四）部分限定名称格式。
Not that I'm aware of, rather it looks like someone is lazy.
I always use the three name format (unless accessing a linked server instance, then it's four).
The benefit is that the correct table from the correct database & schema will be used without concern for an errant
USE [appropriate database]statement. As long as the object exists, and the permissions are valid based on the need, you can recreate a stored procedure, function, view, etc in other databases without needing to address theUSE [appropriate database]statement each time.But I'm working with data spread over numerous databases on the same instance. I wouldn't have necessarily designed it that way, but it wouldn't change that I use three (or four) part qualified name format.