많은 사람들이 선택 쿼리에서 원하는 각 열의 이름을 구체적으로 지정해야한다고 주장했습니다.
어쨌든 모든 열을 사용한다고 가정하면 왜 사용하지 SELECT *않습니까?
심지어 질문을 고려 * SQL 쿼리 - 선택 *보기 또는 선택 COL1, COL2에서 ... colN이보기에서 *, 나는 약간 다른 관점에서 문제에 접근하고있어 같은이 정확한 중복 생각하지 않습니다.
우리의 원칙 중 하나는 시간이 지나기 전에 최적화하지 않는 것입니다. 이를 염두에두고 리소스 문제로 입증되거나 스키마가 거의 설정 될 때까지 사용 SELECT *하는 것이 선호되는 방법 인 것처럼 보입니다 . 우리가 알고 있듯이 개발이 완전히 완료 될 때까지 발생하지 않습니다.
즉, 사용하지 않는 가장 중요한 문제가 SELECT *있습니까?
답변:
조기에 최적화하지 않는다는 인용의 본질은 간단하고 간단한 코드를 찾은 다음 프로파일 러를 사용하여 핫스팟을 지적하여 효율적으로 최적화 할 수 있다는 것입니다.
select *를 사용하면 프로파일 링이 불가능하므로 명확하고 간단한 코드를 작성하지 않으므로 인용의 정신에 위배됩니다. select *안티 패턴입니다.
따라서 열 선택은 조기 최적화가 아닙니다. 내 머리 꼭대기에서 몇 가지 ....
그 결과는 select *...
올바른 SQL을 작성하는 것은 작성하는 것만 큼 쉽습니다 Select *. 실제 게으른 사람은 코드를 다시 방문하지 않고 코드를 다시 작성하고 싶지 않았기 때문에 적절한 SQL을 작성합니다. 그들은 모든 코드 비트에 대해 DBA에 설명하고 싶지 않습니다. 그들은 왜 응용 프로그램이 개처럼 실행되는지 고객에게 설명하고 싶지 않습니다.
코드가 특정 순서의 열에 의존하는 경우 테이블이 변경되면 코드가 중단됩니다. 또한 *를 선택할 때 특히 테이블에 이진 필드가있는 경우 테이블에서 너무 많은 페치가 발생할 수 있습니다.
지금 모든 열을 사용한다고해서 다른 사람이 테이블에 추가 열을 추가하지 않는다는 의미는 아닙니다.
또한 테이블에 대한 메타 데이터를 가져 와서 *에있는 열을 알아야하기 때문에 계획 실행 캐싱에 오버 헤드를 추가합니다.
로터리 방식으로 가능한 한 엄격한 타이핑을 사용하는 것에 대한 모듈화 규칙을 위반하고 있습니다. 명시 적으로 거의 보편적으로 좋습니다.
이제 테이블의 모든 열이 필요하더라도 나중에 쿼리를 실행할 때마다 풀다운되어 성능이 저하 될 수있는 추가 열이 추가 될 수 있습니다. 성능이 저하되므로
QUERY를 기록 할 당시 존재했던 테이블의 모든 열이 필요하지 않고, 테이블의 모든 열을 명시 적으로 필요로하는 경우. 예를 들어, 테이블의 전체 내용을 표시하는 데 필요한 DB 관리 앱을 작성하는 경우 (어떤 일이 있었 든) 해당 방식을 사용할 수 있습니다.
SELECT *은 db 클라이언트를 사용하여 테스트 쿼리를 할 때입니다.
몇 가지 이유가 있습니다.
참고 : 위의 예제에서는 고정 크기가 4 바이트이므로 INTEGER를 선택했습니다.
응용 프로그램에서 SELECT *를 사용하여 데이터를 가져오고 데이터베이스의 테이블 구조가 변경되면 (예 : 열 제거) 누락 된 필드를 참조하는 모든 위치에서 응용 프로그램이 실패합니다. 대신 쿼리에 모든 열을 포함 시키면 응용 프로그램이 처음에 데이터를 얻는 위치 (바람직하게)에서 깨져서 수정이 쉬워집니다.
즉, SELECT *가 바람직한 여러 가지 상황이 있습니다. 하나는 항상 전체 테이블을 다른 데이터베이스 (예 : SQL Server에서 DB2로)로 복제해야하는 상황입니다. 다른 하나는 일반적으로 테이블을 표시하도록 작성된 응용 프로그램입니다 (즉, 특정 테이블에 대한 지식이 없음).
실제로 select *SQL Server 2005의 뷰에서 사용할 때 이상한 동작을 발견했습니다 .
다음 쿼리를 실행하면 무슨 뜻인지 알 수 있습니다.
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[starTest]') AND type in (N'U'))
DROP TABLE [dbo].[starTest]
CREATE TABLE [dbo].[starTest](
[id] [int] IDENTITY(1,1) NOT NULL,
[A] [varchar](50) NULL,
[B] [varchar](50) NULL,
[C] [varchar](50) NULL
) ON [PRIMARY]
GO
insert into dbo.starTest
select 'a1','b1','c1'
union all select 'a2','b2','c2'
union all select 'a3','b3','c3'
go
IF EXISTS (SELECT * FROM sys.views WHERE object_id = OBJECT_ID(N'[dbo].[vStartest]'))
DROP VIEW [dbo].[vStartest]
go
create view dbo.vStartest as
select * from dbo.starTest
go
go
IF EXISTS (SELECT * FROM sys.views WHERE object_id = OBJECT_ID(N'[dbo].[vExplicittest]'))
DROP VIEW [dbo].[vExplicittest]
go
create view dbo.[vExplicittest] as
select a,b,c from dbo.starTest
go
select a,b,c from dbo.vStartest
select a,b,c from dbo.vExplicitTest
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[starTest]') AND type in (N'U'))
DROP TABLE [dbo].[starTest]
CREATE TABLE [dbo].[starTest](
[id] [int] IDENTITY(1,1) NOT NULL,
[A] [varchar](50) NULL,
[B] [varchar](50) NULL,
[D] [varchar](50) NULL,
[C] [varchar](50) NULL
) ON [PRIMARY]
GO
insert into dbo.starTest
select 'a1','b1','d1','c1'
union all select 'a2','b2','d2','c2'
union all select 'a3','b3','d3','c3'
select a,b,c from dbo.vStartest
select a,b,c from dbo.vExplicittest마지막 2 개의 select 문의 결과를 비교하십시오. 나는 당신이 볼 것의 결과는 이름 대신 인덱스로 열을 참조 Select * .
뷰를 다시 빌드하면 다시 정상적으로 작동합니다.
편집하다
SQL Server 2005의 흥미로운 동작 인“테이블에서 선택 *”과“테이블에서 colA, colB 등 선택”과 같은 별도의 질문을 추가했습니다 .
SELECT * 가 항상 악한 것은 아닙니다. 제 생각에는 적어도. 전체 테이블과 일부 계산 필드를 반환하는 동적 쿼리에 자주 사용합니다.
예를 들어, "일반"테이블에서 지오메트리를 계산하려고합니다. 즉, 지오메트리 필드는 없지만 좌표를 포함하는 필드가있는 테이블입니다. postgresql과 공간 확장 postgi를 사용합니다. 그러나 원칙은 다른 많은 경우에도 적용됩니다.
예를 들면 :
x, y, z로 표시된 필드에 좌표가 저장된 장소 테이블 :
CREATE TABLE 자리 (place_id 정수, x 숫자 (10, 3), y 숫자 (10, 3), z 숫자 (10, 3), 설명 varchar);
몇 가지 예제 값으로 공급해 보겠습니다.
장소에 삽입 (place_id, x, y, z, 설명) 값
(1, 2.295, 48.863, 64, '파리, Place de l \'Étoile '),
(2, 2.945, 48.858, 40,'파리, 에펠 투어 '),
(3, 0.373, 43.958, 90,'콘돔, Cathédrale St-Pierre ');
일부 GIS 클라이언트를 사용하여이 테이블의 내용을 매핑 할 수 있기를 원합니다. 일반적인 방법은 테이블에 형상 필드를 추가하고 좌표를 기반으로 형상을 작성하는 것입니다. 그러나 동적 쿼리를 선호합니다.이 방법으로 좌표 (수정, 정확도 등)를 변경하면 매핑 된 객체가 실제로 동적으로 이동합니다. 다음은 SELECT *를 사용한 쿼리입니다 .
뷰 생성 또는 교체 place_points AS
SELECT *,
GeomFromewkt ( 'SRID = 4326; POINT ('|| x || ''|| y || ''|| z || ')')
FROM 플레이스;
GeomFromewkt () 함수 사용에 대해서는 postgis를 참조하십시오.
결과는 다음과 같습니다.
places_points에서 선택 *;
place_id | x | y | z | 설명 | geomfromewkt
---------- + ------- + -------- + ---------- + --------------- ----------------- + -------------------------------- ------------------------------------
1 | 2.295 | 48.863 | 64.000 | 파리, Place de l' Étoile | 01010000A0E61000005C8FC2F5285C02405839B4C8766E48400000000000005040
2 | 2.945 | 48.858 | 40.000 | 파리, 에펠 탑 | 01010000A0E61000008FC2F5285C8F0740E7FBA9F1D26D48400000000000004440
3 | 0.373 | 43.958 | 90.000 | 콘돔, Cathédrale St-Pierre | 01010000A0E6100000AC1C5A643BDFD73FB4C876BE9FFA45400000000000805640
(3 리그)
이제 GIS 프로그램에서 가장 오른쪽 열을 사용하여 점을 올바르게 매핑 할 수 있습니다.
VIEW의 정의가 *와 함께 "있는 그대로"유지 될 수 있기를 바라지 만, 실제로는 그렇지 않습니다. postgresql에 의해 내부적으로 저장되는 방식입니다.
places.place_id, places.x, places.y, places.z, places.description, geomfromewkt (((((((((((((( '(:( text : || 텍스트 || places.x) || places.x) ||') :) '': : text) || places.y) || '':: text) || places.z) || ')':: text) AS geomfromewkt FROM 플레이스;
아무도 언급하지 않은 것을 추가하십시오. Select *모든 열을 반환합니다. 누군가 열을 추가하면 나중에 사용자가 데이터를 마지막으로 업데이트 한 사람이나 타임 스탬프 또는 관리자 만 모든 사용자를 볼 수 없다는 메모 등 사용자가 볼 수있는 것을 원하지 않을 수 있습니다.
또한 열을 추가 할 때 기존 코드에 미치는 영향을 검토하고 열에 저장된 정보에 따라 변경이 필요한지 검토해야합니다. 를 사용 select *하면 개발자가 아무것도 깨지지 않을 것이라고 가정하기 때문에 해당 검토를 종종 건너 뜁니다. 실제로 실제로는 아무것도 깨지는 것처럼 보이지 않지만 쿼리는 이제 잘못된 것을 반환하기 시작할 수 있습니다. 명시 적으로 중단되는 것이 없다고해서 쿼리가 변경되어서는 안된다는 의미는 아닙니다.