MySQL에서는 3 열 또는 100 열을 갖는 100 개의 행을 반환하는 것이 일반적으로 더 빠르거나 더 효율적/확장 가능합니까?더 빠릅니다 : 많은 행 또는 많은 열?
즉, 레코드와 관련된 많은 key => value 쌍을 저장할 때 record_id를 키로 사용하여 별도의 행에 각 key => value 쌍을 저장하는 것이 좋습니다. 각 키에 대한 열이있는 record_id?
또한 정기적으로 키를 추가/제거해야합니다. 테이블이 충분히 커지면 많은 열 접근법의 장기 유지 관리 가능성에 영향을 미칠 것으로 생각됩니다.
편집 : 명확히하기 위해 "정기적으로"는 한 달에 한 번 정도 키 추가 또는 제거를 의미합니다.
정기적으로 열을 추가하거나 제거해서는 안됩니다.
키가 미리 설정되어있는 경우 (디자인 타임에 알려짐) 그렇다면 각 키를 별도의 열에 넣어야합니다.
디자인 타임에 알 수없는 경우 나중에 RDBMS 외부에서 구문 분석해야하는 키 - 값 쌍의 목록으로 데이터를 반환해야합니다.
키/값 쌍을 저장하는 경우 키 (테이블의 PK로 설정)와 값 (두 개의 열이있는 테이블이 있어야합니다.). "열쇠, 전체 열쇠, 그리고 열쇠 만 기억하십시오."
다중 열 접근법에서는 열 제거가 모든 값을 무시하고 수행하지 않으므로 표가 바운드없이 증가한다는 것을 알 수 있습니다. 나는 거의 1000 개의 열을 가진 하나의 테이블을 가지고있는 레거시 시스템에서 작업 한 경험이 있습니다. 대부분은 비트 필드였습니다. 결국 누군가 일 수도 있고 일 수 있으므로 마지막 열까지 백업을 롤백 할 때까지 열을 삭제할 수 없게됩니다.
http://en.wikipedia.org/wiki/Entity-Attribute-Value_model
이 모델에 대한 나쁜 일이 많이 있습니다 및 다른 대안이 있다면 나는 그것을 사용하지 않을 것입니다. 응용 프로그램에 필요한 데이터 열의 대다수 (사용자가 사용자 정의 할 수있는 몇 가지 필드 제외)를 모르는 경우 설계에 더 많은 시간을 할애해야합니다.
첫 번째 : 데이터에 액세스해야하는 빈도를 결정하십시오. 데이터를 항상 한 번에 검색해야하며 대부분의 경우에는 모든 키 쌍을 직렬화 된 값 또는 xml 값으로 저장하는 것이 좋습니다. 해당 데이터에 대해 복잡한 분석을 수행해야하는 경우 값 쌍이 필요하면 열은 정상이지만 쿼리를 수행해야하는 값으로 제한됩니다. 일반적으로 행보다 한 매개 변수에 대해 한 열을 사용하는 쿼리를 디자인하는 것이 더 쉽습니다. 또한 모두가 한 행에 모두있는 경우 반환 값을 과 함께 사용하는 것이 더 쉽습니다.
둘째 : 자주 액세스하는 데이터를 분리하여 자체 테이블에 넣고 다른 데이터를 다른 테이블에 넣습니다. 100 열은 많은 양이 많으므로 데이터를 더 관리하기 쉬운 작은 덩어리로 분할하는 것이 좋습니다.
마지막으로 자주 변경되는 데이터가있는 경우 한 테이블에서 열 (키)을 만든 다음 키 값을 저장할 숫자 키 값을 사용해야합니다.이 경우 동일한 키를 두 번 이상 사용하게되며 조회를 수행 할 때 검색 속도가 빨라집니다.
한 달에 한 번 정기적으로합니다. 기본적으로 애플리케이션을 프로덕션 환경으로 옮기면 데이터베이스 스키마를 변경해서는 안됩니다. 단, 비즈니스 요구 사항이 근본적인 방식으로 변경되는 경우는 예외입니다. –
이 답변은 더 많은 열 또는 더 많은 행을 가진 스키마가 더 빠른 쿼리를 생성하는지 여부와 같은 질문에 대답하지 않습니다. 또한이 대답에는 소프트웨어 개발의 실제 성을 반영하지 않는 설명이 없습니다. 나는 왜이 대답이 "정확한"대답인지 이해하지 못한다. – GregT