위키백과:도구/내비게이션 팝업/수정 리디렉션

일부 팝업 사용자는 팝업 FixRedirs 기능을 부적절하게 사용하고 있다. 그들은 이 기능을 사용하는 것이 위키백과 서버의 작업을 줄이는 것이라고 생각하지만, 사실 그들은 위키백과 서버가 해야 할 일을 늘리고 있다.

예를 들어, 완전히 합법적인 리디렉션 링크(모폴로신택스가 모폴로지(언어학)로 리디렉션됨)를 만난다고 가정하십시오.

팝업FixRedirs 기능을 사용하면 형태 변환 링크를 가리키고 리디렉션을 클릭한 다음 텍스트를 다음과 같이 변경할 수 있다.

(참고: 이 페이지에서는 사용하지 마십시오. 팝업은 리디렉션의 모든 사례를 페이지에서 찾을 수 있도록 수정하므로 "수정"하면 이 텍스트는 의미가 없다.)

새로운 위키텍스트는 리디렉션을 피하고 '올바른 페이지'로 '직진'되기 때문에 위키백과 서버에 '더 나은' 것이 틀림없고, '나쁜' 링크를 '고치는' 방법으로 훌륭한 서비스를 수행하고 있는 거지? 불행히도, 아마 아닐 것이다.

다음과 같은 이유:

• 누군가 리디렉션 링크(예: morphosyntax)를 클릭하면 MediaWiki 소프트웨어는 SQL 쿼리를 수행하여 대상 페이지를 찾는다. 이 쿼리는 요청된 대상이 리디렉션인지 여부(모든 페이지에는 page.page_is_redirect라는 데이터베이스 필드가 포함됨)에 대한 검사를 포함하며, 이 경우 리디렉션된 페이지의 위치를 반환한다. 즉, 직접 링크보다 리디렉션을 따르는 것이 더 비싸다는 것은 기술적으로 사실이지만, 그것은 가장 작은 머리카락일 뿐이다. (관심하는 사람들의 경우, 2006년 버전의 MediaWiki의 실제 숫자는 직접 링크를 따르는 44개의 SELECT 문장이었고, 리디렉션을 따르는 것은 48개였다.)
• 팝업을 사용하여 리디렉션을 수정할 경우 MediaWiki는 리디렉션을 따르는 데 필요한 것보다 더 많은 SQL 쿼리를 수행해야 하지만 여러 데이터베이스 트랜잭션과 쓰기도 해야 한다. (정확히 말하면, 같은 버전의 MediaWiki에서 SELECT 64개, UPDATE 10개, INSERT 4개, DELETE 2개로 8개의 트랜잭션)
• 데이터베이스 업데이트(즉, 쓰기 작업)는 데이터베이스 쿼리보다 서버에서 훨씬 더 비용이 많이 드는 몇 가지 순서, 즉 읽기 작업이다. 2006년 1월에 실행된 벤치마크는 리디렉션을 수정하는 것이 리디렉션을 따르는 것보다 서버에게 약 만 배 더 비싸다는 것을 보여주었다.

다시 말해, 위키피디아의 독자들은 그 링크를 직접 연결로 대체하는 것이 가치가 있기 전에 약 1만 번 정도 리디렉션 링크를 사용해야 할 것이다. 어떤 경우든 위키백과:성능에 대해 염려하지 마십시오. 위키피디아 사람들이 성능에 대해 걱정하는 것을 방해하므로, 처음부터 서버의 부하를 줄이기 위해 리디렉션을 수정하지 마십시오.

많은 리디렉션을 수정하지 않을 최종적이고 더 중요한 이유가 있다. 리디렉션 페이지는 리디렉션된 항목에서 관련되는 다른 주제에 대한 것일 수 있으며, 누군가가 나중에 페이지를 작성하기를 원할 수 있다. 이러한 페이지는 가능한 리디렉션이다. 이러한 페이지가 생성되면 "고정" 리디렉션은 부정확한(또는 덜 정확한) 페이지를 가리킨다.

참고 항목

• 위키백과:리디렉션#손상되지 않은 리디렉션에 대한 링크를 "수정"하지 않음