나는 잠시 동안 버그로 고전하고 데이터베이스의 이전 이름이 들어있는 데이터베이스 저장 프로 시저 코드에서 그 이유를 알아 냈습니다. 테이블 이름은 현재 데이터베이스 이름이 이미 다른 반면. 그래서, 내가 물어보고 싶습니다
전체 테이블 이름에 대해 SQL 스크립트 내에서 데이터베이스 이름 사용
제공 정당화 될 수있는 전체 테이블 이름 (데이터베이스 이름 + 스키마 이름 + 테이블 이름)의 일부로 데이터베이스 이름을 사용하여 상황 (거기 우리는 다른 데이터베이스의 테이블을 만지지 않습니다) 또는 항상 나쁜 습관입니까? SQL 스크립트에서 데이터베이스 이름을 올바르게 사용하여 코드를 특정 데이터베이스에 중립으로 유지하는 방법은 무엇입니까? 단지 그림
코드 :
CREATE PROCEDURE [dbo].[MyProc]
AS
BEGIN
DELETE FROM [MyDatabase].[dbo].[MyTable]
END
아니, 당신은 저장 프로 시저에서 데이터베이스 이름을 사용해서는 안됩니다.
정확하게보고있는 버그의 원인이됩니다. 데이터베이스 이름이 변경되면 모든 SP 코드가 중단되거나 이전 데이터베이스에서 계속 작동하지만 계속됩니다.
SQL 쿼리를 데이터베이스로 보내는 경우 응용 프로그램이 동적으로 쿼리에 삽입 할 데이터베이스 이름을 선택하는 경우에만 의미가 있습니다.
내 제안은 데이터베이스 스키마를 완전히 내보내고 하드 코딩 된 데이터베이스 이름을 검색하여 제거하는 것입니다.
정말 스크립트 구현 방법에 따라 달라집니다. 당신이
[MyDatabase].[dbo].[MyTable]
으로 테이블을 참조하지 않는 경우에도 당신은 여전히하여 데이터베이스를 참조해야합니다
USE [MyDatabase]
이전 스크립트입니다.
신뢰할 수있는 데이터베이스 테이블을 단일 쿼리로 혼합 할 수 있습니다. 누군가 이렇게하면 '경로'테이블에 데이터베이스를 포함하는 것이 정당화되고 필수적입니다.
저장 프로 시저와 테이블이 동일한 데이터베이스에있는 경우이 시나리오의 원인을 찾을 수 없습니다.
개발을 수정하기 위해 데이터베이스 카탈로그를 통해 모든 데이터베이스 이름 항목을 검색 할 수 있습니다. SQL 서버 2000
SELECT Name
FROM sys.procedures
WHERE OBJECT_DEFINITION(OBJECT_ID) LIKE '%databasename%'
GO
: SQL Server 2005를 들어 당신이 두 개의 데이터베이스를 해결하기 위해 필요하지 않는
SELECT DISTINCT so.name
FROM syscomments sc
INNER JOIN sysobjects so ON sc.id=so.id
WHERE sc.TEXT LIKE '%databasename%'
GO