내 CMS 용 현지화 플러그인을 작성하고 있습니다. 이 작업을 수행 할 수있는 옵션이 있지만 가장 쉬운 방법은 title_en, content_en과 같은 각 언어에 대한 추가 열을 만드는 것입니다.내 프로젝트, 더 많은 열 또는 더 많은 행의 성능에 가장 적합한 것이 하나 있습니까?
다른 방법으로 '언어'라는 열을 만들고 각 기사의 각 언어를 만들어 행을 만듭니다. 그러나 동적 영역은 '제목', '내용'및 'nice_url'이지만 10 열 (id, category, display, date ...)이 있으며 이러한 열은 필요하지 않습니다.
다른 방법 (예 : article_translations라는 추가 테이블 만들기)은 내 CMS의 플러그인 알고리즘에 적합하지 않습니다.
더 많은 열을 확장 할 수 없으며 열보다 행을 쉽게 추가 할 수 있습니다.
각 언어의 데이터에 대한 행을 갖는 것이 좋습니다.
많은 정보를 게시하지 않았지만 모든 공통 데이터를 하나의 테이블에 넣고 언어 별 외래 키 또는 열거 형을 사용하여 언어 별 데이터를 다른 하위 테이블에 저장하십시오. 저장/검색하려는 언어에 대한 정보가있는 경우 언어 테이블에 대한 외래 키를 사용하십시오. 값을 확인하려면 열거 형을 사용하고, 그렇지 않은 경우 텍스트 만 사용하십시오.
또한 한 번에 둘 이상의 언어를 사용하기는 쉽지 않으므로 하나의 행에 모든 언어에 대한 모든 정보가 들어있는 매우 넓은 테이블을 사용하는 것이 이점이 없습니다.
해결 방법은 지원할 언어의 언어 수에 따라 다릅니다. 몇 가지 추가 열을 아무 문제없이 추가 할 수 있습니다. 이 모델을 언어 간 전환에 사용하기 쉽습니다. 그러나 많은 언어를 사용할 계획이라면 추가 표를 생각해야한다고 생각합니다.
사용자는 일반적으로 4-5 개 언어를 사용하며 총 15 개 열 (제목, 콘텐츠, nice_url)을 의미합니다. 그것은 문제가 되는가? –
특정 언어 번역을 저장하는 하위 테이블을 만드는 것이 좋습니다. 그렇다면 번역만큼 많은 레코드가 있으며, 번역이없는 경우 null/default 레코드로 가득 찬 테이블로 끝나지 않습니다. –
아니요,이 표로 검색 할 필요가 없다면 문제가되지 않습니다. 테이블이 커질 것이기 때문에 InnoDB를 사용하면 큰 인덱스와 기본 키를 얻을 수 있습니다. –
실제로 "더 많은 행"방식을 사용하면 owner_article이라는 추가 열을 만들어야하고 삭제, 업데이트 및 편집과 같은 모든 요청을 확인하고 업데이트해야하기 때문에 실제로 프로젝트를 구현하기가 쉽습니다. –
저장해야하는 데이터에 대한 추가 정보를 게시하십시오. 우리가하려는 일에 대해 더 많이 알면 더 잘 도울 수 있습니다. – Bohemian
기사가 있으며 각 기사는 몇 가지 언어로 작성됩니다. 기사가 가지고있는 기능은 모든 번역에서 사용됩니다. 만약이 기능을 내 CMS에 구현했다면 쉽다.하지만 플러그인이 될 것이다. "더 많은 행"을 사용하면 실제로 플러그인에 적합하지 않기 때문에 플러그인을 만드는 방식에서 많은 것들을 바꿔야한다. 특색. –