기존 Drupal 필드를 재사용해야 합니까?

때때로 우리는 정말 명확한 조언을 할 수 있습니다. "이렇게 하세요!" 또는 "하지마!"

이것은 블로그 게시물 중 하나가 아닙니다.

Drupal은 필드를 재사용할 수 있는 기능을 제공합니다. "이미지" 필드가 있는 경우 사이트의 모든 콘텐츠 유형에 동일한 필드를 사용하도록 선택할 수 있습니다. 그러나 필드를 재사용하는 것이 좋은 생각인지 여부가 항상 명확한 것은 아닙니다. 그럴 때도 있고 아닐 때도 있습니다.

다음은 Drupal 필드를 재사용하기 전에 고려해야 할 장단점에 대한 개요입니다.

필드 재사용에 대한 일반적인 조언

"구조"로 이동한 다음 "콘텐츠 유형"으로 이동하고 콘텐츠 유형에 대해 "필드 관리"를 클릭할 때마다 "기존 필드 재사용" 기능을 선택할 수 있습니다.

Drupal.org 문서에서는 필드를 재사용하지 말라고 공식적으로 권장합니다.

명확한 이유가 없는 한 기존 필드를 재사용하는 것보다 새 필드를 만드는 것이 좋습니다.

그러나 그 조언은 최근 몇 년 동안 더욱 미묘해졌으며 Drupal은 공식적으로 그것이 장점이자 단점이라고 말합니다.

Drupal Field UI 문서에는 "Reusing Fields"라는 자세한 섹션이 있습니다.

필드를 재사용하는 두 가지 주요 이유가 있습니다. 첫째, 필드를 재사용하면 새 필드를 정의하는 시간을 절약할 수 있습니다. 둘째, 필드를 재사용하면 콘텐츠 유형 전반에 걸쳐 필드별로 콘텐츠를 함께 표시, 필터링, 그룹화 및 정렬할 수 있습니다. 예를 들어 제공된 보기 모듈을 사용하면 목차와 목록을 만들 수 있습니다. 따라서 여러 콘텐츠 형식에서 동일한 필드를 사용하는 경우 해당 필드를 기준으로 정렬 및/또는 해당 필드를 기준으로 필터링하여 해당 필드를 표시하는 모든 콘텐츠 형식을 함께 포함하는 보기를 만들 수 있습니다. 필드를 재사용하지 않는 주된 이유는 다른 권한입니다. 예를 들어 필드가 추가된 콘텐츠 유형에 따라 필드에 대한 다른 액세스 수준을 갖기 위해 다른 사용자 역할이 필요할 수 있습니다. 필드를 재사용하는 경우 어려울 수 있습니다.

장점: 필드를 재사용하면 더 간단하게 만들 수 있습니다.

예, 속도 향상이 있을 수 있지만 시간 절약은 매우 적습니다. 보다 강력한 이점은 필드를 재사용하면 때때로 사이트 관리를 더 간단하게 만들 수 있다는 것입니다. Web Initiative는 이를 다음과 같이 멋지게 요약합니다.

필드를 재사용하면 시스템의 복잡성도 줄일 수 있습니다. Drupal 관리자는 10개의 다른 필드를 만들고 유지하는 대신 두 개의 필드와 해당 문서만 유지 관리합니다. 데이터베이스 관리자는 두 개의 추가 테이블의 성능을 향상시키기만 하면 됩니다. KISS는 항상 좋은 원칙입니다.

10개의 고유한 필드보다 1개의 재사용된 필드에 권한, 설정 및 디자인 요소를 적용하는 것이 확실히 더 쉬울 것입니다.

장점: 일부 콘텐츠는 재사용된 필드에서 잘 작동합니다.

Drupal Field UI 설명서로 다시 돌아가십시오.

필드를 재사용하면 콘텐츠 유형 전반에 걸쳐 필드별로 콘텐츠를 함께 표시, 필터링, 그룹화 및 정렬할 수도 있습니다. 예를 들어 제공된 보기 모듈을 사용하면 목차와 목록을 만들 수 있습니다. 따라서 여러 콘텐츠 형식에서 동일한 필드를 사용하는 경우 해당 필드를 기준으로 정렬 및/또는 해당 필드를 기준으로 필터링하여 해당 필드를 표시하는 모든 콘텐츠 형식을 함께 포함하는 보기를 만들 수 있습니다.

Drupal.org 문서의 한 주석 작성자는 Views에 대해 같은 점을 지적합니다. 그들은 보기가 정교한 방식으로 콘텐츠를 결합할 수 있다고 지적합니다. 따라서 날짜 필드가 서로 다른 여러 콘텐츠 유형이 있는 경우 보기에서 이를 단일 보기로 결합할 수 있습니다. 그러나 그들은 또한 View가 정렬과 관련하여 그렇게 정교하지 않다는 점을 지적합니다. 따라서 날짜 필드가 서로 다른 여러 콘텐츠 유형이 있는 경우 View는 모든 다른 날짜 필드에서 콘텐츠를 정렬하는 데 어려움을 겪을 것입니다.

단점: 재사용된 필드는 유연하지 않습니다.

트위터의 Brandon Williams는 이를 멋지게 요약했습니다.

처음에는 좋은 생각이지만 몇 주만 기다리면 요구 사항이 변경되므로 결국 별도의 항목을 생성하게 됩니다.

재사용된 필드를 선택하면 나중에 데이터에 쉽게 적용할 수 있는 변경 사항이 크게 제한됩니다. 또한 각 필드를 개별적으로 편집해야 하기 때문에 업데이트하는 데 훨씬 더 많은 시간이 소요됩니다.

단점: 필드를 재사용하면 데이터를 내보내거나 마이그레이션하기가 더 어려워집니다.

데이터를 내보내야 하거나 Drupal의 새 버전이나 다른 플랫폼으로 마이그레이션해야 할 때 필드 재사용이 문제가 될 수 있습니다.

각 Drupal 필드에는 아래와 같이 자체 데이터베이스 테이블이 있습니다. 해당 데이터를 추출하는 것은 어려울 수 있습니다. 기능 모듈(Drupal 데이터를 내보내는 가장 일반적인 방법)은 현재 버전이 더 효율적으로 처리할 수 있지만 공유 필드로 오랫동안 어려움을 겪었습니다.

이 조언은 다중 사이트 사용에 대한 우리의 생각과 유사합니다. 코드베이스 또는 데이터베이스 테이블 간의 종속성을 구축하기 시작할 때마다 사이트에 복잡성이 추가됩니다.

장점 또는 단점? 성능

Drupal 문서에는 필드 재사용의 한 가지 가능한 이점이 설명되어 있습니다.

필드를 재사용하면 Drupal이 더 빠르게 실행될 뿐만 아니라 프로젝트를 더 쉽게 유지 관리할 수 있습니다.

스택 오버플로의 이 스레드에는 성능에 대한 매우 관련성이 높은 토론이 있습니다. 여기에는 다음 주석이 포함됩니다.

그러나 실제 문제는 보유한 필드의 수입니다. 현재 Drupal 7에서는 로드 여부에 관계없이 모든 필드의 전체 필드 구성이 모든 단일 요청에서 캐시에서 가져오기 때문입니다. 필드 구성을 로드 및 직렬화 해제하는 데 13MB 이상의 메모리가 필요한 250개 이상의 필드가 있는 사이트를 보았습니다."

따라서 필드를 재사용하면 총 필드 수를 줄여 성능을 약간 향상시킬 수 있습니다.

그러나 이러한 작은 개선 사항은 다른 곳에서 손실될 수 있습니다. 이것은 Web Initiative에서 다시:

[필드] Drupal 시스템에 추가 복잡성. 새 필드를 만들 때 필드의 정의가 필드 클래스 테이블에 추가되고 필드의 구성이 필드 인스턴스 테이블에 추가됩니다. 한편, 필드 데이터를 저장하기 위해 Drupal 데이터베이스에 새 테이블이 추가됩니다. 데이터베이스 테이블은 시스템에 복잡성을 더합니다. 또한 노드 쿼리는 필드 데이터에 대한 테이블의 JOIN 표현식을 발생시킵니다. MySQL이 적절하게 구성되지 않은 경우 테이블의 다중 JOIN이 있는 쿼리에 제대로 응답하지 않기 때문에 다중 JOIN은 데이터베이스 성능에 영향을 미칩니다.

요약

이 질문에 대한 쉬운 답변을 드리지 못해 죄송합니다. 이것은 문제를 읽고 찬반 양론을 이해함으로써 이익을 얻을 수 있는 질문입니다. 실제 사이트 빌드를 수행하는 경우 이러한 장단점이 사이트 요구 사항에 미치는 영향에 대해 자세히 알아보기 위해 테스트 환경에서 사이트를 구성할 가치가 있습니다.