보기에서 선택 *을 사용하는 것이 안전합니까?

Question

저는 CREATE VIEW의 유용성을 아주 좋아했습니다. 예를 들어 COALESCE(post.publish, profile.publish)을 통해 전역 및 특정 값을 가질 수 있으므로 publish이 NULL 인 경우 전역 값이 대신 가져옵니다.

성능과 논리적 관점에서 약간 궁금한 부분은 기존 테이블과 함께 사용해야합니다.

CREATE VIEW post_info AS 
SELECT post.*, COALESCE(post.publish, profile.publish) AS publish 
FROM post 
INNER JOIN profile 
ON post.profile_id = profile.id 

만 post_infoSELECT의 경우, 또는 사용 :

CREATE VIEW post_info AS 
SELECT post.id, COALESCE(post.publish, profile.publish) AS publish 
FROM post 
INNER JOIN profile 
ON post.profile_id = profile.id 

그리고 JOINpost_info을

CREATE TABLE post (
    id INT, 
    profile_id INT, 
    name VARCHAR, 
    publish ENUM('TRUE', 'FALSE') NULL 
) 

가 CREATE VIEW 같이 실행하는 데 가장 좋은 것입니다 : 나는 테이블이 있다고 가정하자 post에 SELECT 추가 값이 필요한 경우?

이 문제에 대한 귀하의 통찰력과 생각을 공유하십시오. 각 솔루션의 장점과 단점에 대한 의견을 듣고 싶습니다. 내가 언급하지 않은 사람이 될 수도 있습니다.

Answer 1

정말 어떻게 전망을 사용 하느냐에 달려 있습니다. MySQL이 뷰를 참조하는 쿼리를 처리 할 수있는 두 가지 메소드가 있으며, 사용 된 메소드는 뷰 선언의 ALGORITHM 절에 의존한다는 것을 언급 할 가치가있다.

더 나은 말씨의 부족을

, 나는 the manual를 재현하는 것입니다 :

[ALGORITHM =] MERGE를 들어,보기와 뷰 정의에 참조하는 문의 텍스트는 합병 것을하는 뷰 정의의 일부 은 해당 부분을 대체합니다.

TEMPTABLE의 경우보기의 결과가 임시 테이블로 검색되고이 테이블이 명령문을 실행하는 데 사용됩니다.

UNDEFINED의 경우 MySQL은 사용할 알고리즘을 선택합니다.

는 MERGE 알고리즘은 일반적으로하지만 MySQL은 (자세한 내용은 링크 된 매뉴얼 페이지를 참조)를 사용 할 수없는 많은 경우가있다, 마지막 쿼리의 빠른 처리를 할 수 있습니다.

그래서 대답입니다 :보기는 포장 쿼리 SELECT *으로 MERGE 알고리즘 버전의 사용을 금지하지 않는 경우 ALGORITHM = TEMPTABLE 및으로 정의하고, 추가 JOIN하지 않고, 더 나은되지 않습니다.

그렇지 않으면 MERGE을 사용하지 않으면 두 번째 해법이 더 좋을 수 있습니다. 보조 노트로

는, 당신이 언급 유스 케이스를 ADRESS하기 위해, 더 나은 옵션은 응용 프로그램 계층은 삽입시 profile.publish의 값으로 post.publish에 꽉 차게하고 뷰뿐만 아니라 JOIN 없애 것 . 또는 테이블에 적합한 방아쇠를 놓아도 동일한 효과를 얻을 수 있습니다.