MySQL: 테이블이 여러 개입니까, 열이 많은 테이블이 한 개입니까?
이것은 디자인적인 질문입니다.
프라이머리 키(사용자 ID 등)가 1개 있고, 그 유저와 관련된 정보가 많이 있습니다.
정보에 따라 여러 테이블을 카테고리로 분류해야 합니까, 아니면 열이 많은 테이블을 하나만 사용해야 합니까?
이전에는 예를 들어 애플리케이션 사용률 데이터용 테이블, 프로파일 정보용 테이블, 백엔드 토큰용 테이블 등 여러 개의 테이블을 사용하여 작업을 정리했습니다.
최근에 어떤 사람이 그렇게 하지 않는 것이 좋다고 했고, 많은 기둥으로 된 테이블도 괜찮다고 했습니다.중요한 건 모든 컬럼이 동일한 기본 키를 가지고 있다는 겁니다.
저는 데이터베이스 설계에 익숙하지 않기 때문에 어떤 접근 방식이 더 나은지, 장단점은 무엇입니까?
전통적인 방법은 무엇입니까?
정보가 1대 1(각 사용자마다 이름과 비밀번호가 하나씩 있음)인 경우 데이터베이스가 결과를 검색하기 위해 수행해야 하는 조인 수를 줄이므로 한 개의 테이블을 갖는 것이 좋습니다.일부 데이터베이스는 테이블당 열 수에 제한이 있다고 생각하지만, 일반적인 경우에는 걱정하지 않습니다. 필요하다면 언제든지 나중에 분할할 수 있습니다.
데이터가 일대다(각 사용자가 수천 줄의 사용 정보를 가지고 있음)인 경우 중복 데이터를 줄이기 위해 데이터를 별도의 테이블로 분할해야 합니다(중복 데이터의 경우 스토리지 공간, 캐시 공간이 낭비되고 데이터베이스 유지보수가 더 어려워집니다).
데이터베이스 정규화에 관한 Wikipedia 문서는 그 이유에 대해 자세히 설명하고 있기 때문에 흥미로울 수 있습니다.
데이터베이스 정규화는 다중성과 종속성을 최소화하기 위해 관계형 데이터베이스의 필드 및 테이블을 구성하는 프로세스입니다.정규화에는 보통 큰 테이블을 작은(및 용장성이 적은) 테이블로 분할하여 이들 간의 관계를 정의합니다.목적은 데이터를 분리하여 필드의 추가, 삭제 및 변경을 한 테이블에서만 수행한 후 정의된 관계를 통해 데이터베이스의 나머지 부분으로 전파하는 것입니다.
데이터 읽기 시 데이터베이스가 수행해야 하는 작업량이 줄어들기 때문에 반복 데이터가 더 나은 경우가 있기 때문에 정규화 해제도 주의해야 합니다.데이터를 가능한 한 정규화하고 특정 쿼리의 성능 문제를 알고 있는 경우에만 정규화할 것을 강력히 권장합니다.
큰 테이블 하나가 종종 좋지 않은 선택이다.관련 테이블은 관계형 데이터베이스와 함께 작동하도록 설계된 것입니다.적절한 인덱스를 작성하고 퍼포먼스 쿼리를 작성하는 방법을 알고 있으면 퍼포먼스 쿼리는 정상적으로 동작합니다.
테이블에 열이 너무 많으면 데이터베이스가 정보를 저장하는 페이지의 실제 크기와 관련된 문제가 발생할 수 있습니다.레코드가 페이지에 비해 너무 커서 특정 레코드를 작성하거나 갱신할 수 없게 되어 사용자를 불쾌하게 하거나 (적어도 SQL Server에서) 특정 데이터 유형에 대해 오버플로가 허용될 수 있습니다(이 작업을 수행할 경우 검색해야 하는 규칙 세트를 사용하여) 그러나 많은 레코드가 오버플로가 발생할 수 있습니다.심각한 성능 문제를 일으킬 수 있는 페이지 크기입니다.MYSQL의 페이지 처리 방법 및 잠재적인 페이지 크기가 너무 커졌을 때 문제가 발생하는지 여부는 해당 데이터베이스의 매뉴얼을 참조해야 합니다.
우연히 MySQL을 많이 사용하던 사람이 최근 Postgres로 전환하면서 Postgres의 필드에 JSON 객체를 추가할 수 있는 것이 큰 장점 중 하나입니다.
따라서 이 경우 열이 여러 개 있는 하나의 큰 테이블을 선택하여 분할할 필요는 없지만, 예를 들어 주소가 5열인 대신 열을 JSON 개체로 병합하여 줄일 수 있습니다.또한 해당 개체에 대해 쿼리할 수도 있습니다.
좋은 예가 있습니다.다음과 같은 일련의 관계가 있는 지나치게 정규화된 데이터베이스:
people -> rel_p2staff -> staff
그리고.
people -> rel_p2prosp -> prospects
이름과 인물에 대한 세부 정보가 있는 경우 직원은 직원 기록 세부 정보, 잠재 고객만 있습니다. Rel 테이블은 직원 및 잠재 고객과 연결된 외부 키와의 관계 테이블입니다.
이러한 설계는 데이터베이스 전체에 적용됩니다.
이 일련의 관계를 문의하기 위해 매번 멀티 테이블 조인(때로는 8개 이상의 테이블 조인)을 수행합니다.4만 명 기록을 넘어서면서 매우 느려지기 시작한 올해 중반까지 잘 작동하고 있습니다.
인덱스와 낮은 매달린 과일은 작년에 모두 사용되었으며, 모든 쿼리는 완벽하게 최적화되었습니다.이로써 정규화된 특정 설계 및 관리는 6개월에 걸쳐 애플리케이션 전체의 재구축과 데이터베이스 재구축이 승인되었습니다.$$$$아이고
해결책은 다음과 같은 직접적인 관계를 갖는 것입니다.people -> staff그리고.people -> prospect
모든 것을 1개의 테이블로 정리하면, 그 유저에 대해서 복수의 행이 있는 것입니까?사용자를 업데이트해야 하는 경우 감사 추적을 유지하시겠습니까?사용자는 데이터 요소의 인스턴스를 여러 개 가질 수 있습니까?(예를 들어 전화번호 등) 나중에 요소 또는 요소 세트를 추가할 수 있는 경우가 있습니까?"예"라고 대답하면 외래 키 관계가 있는 하위 테이블을 가질 가능성이 높습니다.
부모/자녀 테이블의 장점은 데이터 무결성, 인덱스를 통한 성능(예, 플랫 테이블에서도 수행 가능), 나중에 필드를 추가해야 할 경우 특히 필수 필드인 경우 IMO를 쉽게 유지 관리할 수 있다는 것입니다.
단점 설계는 어려워지고 쿼리는 약간 복잡해집니다.
하지만 큰 테이블 하나가 적당할 경우가 많기 때문에 자신의 상황을 보고 결정해야 합니다.
데이터베이스 설계 같은 건 이미 끝냈어데이터베이스 관리의 시스템 난이도에 따라 다릅니다.예, 한 곳에 고유 데이터를 보관하는 것은 사실이지만, 기록이 많은 지나치게 정규화된 데이터베이스에서는 쿼리를 작성하는 것이 매우 어렵습니다.2개의 스키마를 조합하는 것만으로, facebook이나 gmail과 같이 관리하기 어려운 대량의 레코드가 있다고 생각되는 경우는, 1개의 테이블을 사용해 심플한 시스템을 실현합니다.음, 이건 그냥 내 의견이야.도움이 됐으면 좋겠는데..그냥 해..넌 할 수 있어...:)
기존의 방법은 스타 스키마나 눈꽃 스키마에서와 같이 다른 테이블을 사용하는 것입니다.하지만, 이 전략은 두 배로 할 수 있을 것 같아요.저는 데이터가 한 곳에만 존재해야 한다는 이론을 믿고 있습니다.제가 말한 스키마는 거기에 잘 들어맞을 겁니다.다만, 보고 엔진이나 BI 스위트에서는, 보고의 요구를 보다 서포트하기 때문에, 기둥형의 어프로치가 큰 메리트가 있다고 생각합니다.infobright.org과 같은 컬럼형 접근방식은 퍼포먼스가 크게 향상되고 압축이 가능하기 때문에 두 접근방식을 모두 사용하면 매우 편리합니다.많은 기업들이 조직 내에 하나의 데이터베이스 아키텍처가 있는 것만으로는 자사의 모든 요구를 지원할 수 없다는 것을 깨닫기 시작하고 있습니다.많은 기업들이 여러 데이터베이스 아키텍처를 갖는다는 개념을 모두 구현하고 있습니다.
저는 단일 테이블이 더 효과적이라고 생각합니다만, 테이블이 같은 행의 변수 차이뿐만 아니라 관계, 차이를 보여주는 방식으로 구성되어 있는지 확인해야 합니다.예를 들어, 만약 그 표에 학생들의 나이와 성적이 나와 있다면, 당신은 가장 높은 점수를 받은 사람들이 가장 낮은 점수를 받은 사람들과 잘 구별되고 학생들의 나이 차이가 고르게 나는 방식으로 표를 정렬해야 한다.
언급URL : https://stackoverflow.com/questions/9774715/mysql-multiple-tables-or-one-table-with-many-columns
'sourcecode' 카테고리의 다른 글
| SQLException이 잘못된 SQL 구문으로 인해 발생함 (0) | 2022.09.21 |
|---|---|
| 속성별로 동일한 개체 인스턴스 비교 (0) | 2022.09.21 |
| 라라벨로 mysql에 접속하려면 어떻게 해야 하나요? (0) | 2022.09.21 |
| PHP에서 블록 시도/캐치 중 예외가 검출되지 않음 (0) | 2022.09.21 |
| PHP7.1 json_encode() 플로트 문제 (0) | 2022.09.21 |