그래서 이것은 디자인 문제에 가깝습니다.
하나의 기본 키 (예 : 사용자 ID)가 있고 해당 사용자와 관련된 많은 정보가 있습니다.
정보에 따라 여러 테이블을 범주로 분류해야합니까? 아니면 여러 열이있는 하나의 테이블 만 가져야합니까?
내가 사용했던 방식은 여러 테이블을 갖는 것이 었습니다. 예를 들어 애플리케이션 사용 데이터 용 테이블 하나, 프로필 정보 용 테이블 하나, 백엔드 토큰 용 테이블 하나 등을 정리하여 정리했습니다.
최근에 어떤 사람은 그렇게하지 않는 것이 낫다고 말했고 많은 열이있는 테이블을 갖는 것이 좋습니다. 문제는 모든 열에 동일한 기본 키가 있다는 것입니다.
저는 데이터베이스 디자인에 익숙하지 않으므로 어떤 접근 방식이 더 좋으며 장단점은 무엇입니까?
기존 방식은 무엇입니까?
답변
정보는 일대일 (각 사용자가 하나의 이름과 암호를 가짐)이면 데이터베이스가 결과를 검색하기 위해 수행해야하는 조인 수를 줄이므로 하나의 테이블을 사용하는 것이 좋습니다. 일부 데이터베이스에는 테이블 당 열 수에 제한이 있다고 생각하지만 일반적인 경우에는 걱정하지 않으며 필요하면 나중에 언제든지 분할 할 수 있습니다.
데이터가 일대 다인 경우 (각 사용자가 수천 행의 사용 정보를 가지고 있음) 중복 데이터를 줄이기 위해 별도의 테이블로 분할해야합니다 (중복 데이터는 저장 공간, 캐시 공간을 낭비하고 데이터베이스를 유지하기 어렵게 만듭니다. ).
데이터베이스 정규화 에 대한 Wikipedia 기사가 흥미로운 이유를 찾을 수 있습니다. 그 이유를 자세히 설명하기 때문입니다.
데이터베이스 정규화는 중복성과 종속성을 최소화하기 위해 관계형 데이터베이스의 필드와 테이블을 구성하는 프로세스입니다. 정규화에는 일반적으로 큰 테이블을 더 작은 (그리고 덜 중복 된) 테이블로 나누고 이들 간의 관계를 정의하는 작업이 포함됩니다. 목표는 데이터를 분리하여 필드의 추가, 삭제 및 수정을 하나의 테이블에서만 수행 한 다음 정의 된 관계를 통해 나머지 데이터베이스에 전파 할 수 있도록하는 것입니다.
비정규 화 는 데이터를 읽을 때 데이터베이스가 수행해야하는 작업의 양을 줄이기 때문에 반복되는 데이터가 더 나은 경우가 있기 때문에주의해야 할 사항입니다. 데이터를 가능한 한 표준화하여 시작하고 특정 쿼리의 성능 문제를 알고있는 경우에만 비정규 화하는 것이 좋습니다.
답변
하나의 큰 테이블은 종종 잘못된 선택입니다. 관련 테이블은 함께 작동하도록 설계된 관계형 데이터베이스입니다. 제대로 인덱싱하고 성능이 좋은 쿼리를 작성하는 방법을 안다면 제대로 수행 될 것입니다.
테이블이 너무 많은 열을 가져 오면 데이터베이스가 정보를 저장하는 페이지의 실제 크기에 문제가 발생할 수 있습니다. 레코드가 페이지에 비해 너무 커져서 사용자를 불편하게 만드는 특정 레코드를 만들거나 업데이트하지 못하거나 (적어도 SQL Server에서) 특정 오버플로가 허용 될 수 있습니다. 데이터 유형 (이 작업을 수행하는 경우 조회해야하는 일련의 규칙 포함)이 있지만 많은 레코드가 페이지 크기를 초과하면 엄청난 성능 문제를 일으킬 수 있습니다. 이제 MYSQL이 페이지를 처리하는 방법과 잠재적 인 페이지 크기가 너무 커질 때 문제가 있는지 여부는 해당 데이터베이스에 대한 문서에서 찾아봐야 할 것입니다.
답변
좋은 예가 있습니다. 다음과 같은 관계 집합이있는 지나치게 정규화 된 데이터베이스 :
people -> rel_p2staff -> staff과
people -> rel_p2prosp -> prospects사람들이 이름과 개인 정보를 가지고있는 경우 직원은 직원 기록 세부 정보 만 있고 잠재 고객은 잠재 고객 세부 정보 만 있으며 rel 테이블은 직원 및 잠재 고객에 연결된 사람들의 외래 키가있는 관계 테이블입니다.
이러한 종류의 디자인은 전체 데이터베이스에 적용됩니다.
이제이 관계 집합을 쿼리하기 위해 매번 다중 테이블 조인이며 때로는 8 개 이상의 테이블 조인입니다. 올해 중반까지 4 만 명의 기록을 넘긴 지금은 매우 느려지기 시작했습니다.
인덱싱 및 모든 낮은 매달려 과일은 작년에 사용되었으며 모든 쿼리는 완벽하게 최적화되었습니다. 이것은 특정 정규화 된 설계 및 관리를위한 도로의 끝이며, 6 개월 동안 데이터베이스의 재구성은 물론 이에 의존하는 전체 애플리케이션의 재 구축을 승인했습니다. $$$$ 아야.
해결책은 다음 people -> staff과 직접적인 관계를 맺는 것입니다.people -> prospect
답변
이것을 발견하고 MySQL을 많이 사용하고 최근에 Postgres로 전환 한 사람으로서 가장 큰 장점 중 하나는 Postgres의 필드에 JSON 객체를 추가 할 수 있다는 것입니다.
따라서 이러한 상황에있는 경우에는 많은 열이있는 하나의 큰 테이블과 분할 중 하나를 반드시 결정할 필요는 없지만 열을 JSON 개체로 병합하여 줄일 수 있습니다. 예를 들어 주소가 5 개 열이 아니라 하나가 되십시오. 해당 개체에 대해서도 쿼리 할 수 있습니다.
답변
모든 것을 하나의 테이블에 넣으면 해당 사용자에 대해 여러 행이 있습니까? 사용자를 업데이트해야하는 경우 감사 추적을 유지 하시겠습니까? 사용자가 데이터 요소의 인스턴스를 두 개 이상 가질 수 있습니까? (예를 들어 전화 번호와 같은) 나중에 요소 또는 요소 집합을 추가하려는 경우가 있습니까? 예라고 대답하면 외래 키 관계가있는 자식 테이블이있을 가능성이 큽니다.
부모 / 자식 테이블의 장점은 데이터 무결성, 인덱스를 통한 성능 (예 : 플랫 테이블에서도 가능) 및 나중에 필드를 추가해야하는 경우, 특히 필수 필드 인 경우 IMO 유지 관리가 더 쉽습니다.
단점 디자인이 더 어렵고 쿼리가 약간 더 복잡 해짐
그러나 하나의 큰 평면 테이블이 적절한 경우가 많으므로 상황을 확인하여 결정해야합니다.
답변
나는 이미 일종의 데이터베이스 설계를 완료했습니다. 저에게는 데이터베이스 관리 시스템의 어려움에 달려 있습니다. 네, 한곳에 만 고유 한 데이터가있는 것은 사실이지만 많은 레코드가있는 지나치게 정규화 된 데이터베이스로 쿼리를 만드는 것은 정말 어렵습니다. 두 스키마를 결합하기 만하면됩니다. 페이스 북, 지메일 등과 같이 관리하기 어려운 방대한 기록이있을 것이라고 생각되면 하나의 거대한 테이블을 사용하십시오. 그리고 간단한 시스템을 위해 한 세트의 레코드에 다른 테이블을 사용하십시오 … 글쎄 이것은 제 의견입니다 .. 도움이 되었으면 좋겠습니다.
답변
이를 수행하는 일반적인 방법은 스타 스키마 또는 눈송이 스키마에서와 같이 다른 테이블을 사용하는 것입니다. Howeevr, 저는이 전략을 두 배로 만들 것입니다. 저는 데이터가 한곳에 만 존재해야한다는 이론을 믿습니다. 제가 언급 한 스키마에 대해서는 잘 작동 할 것입니다. 그러나보고 엔진과 BI 제품군의 경우보고 요구 사항을보다 지원하기 때문에 열 방식의 접근 방식이 매우 유용 할 것이라고 생각합니다. infobright.org와 같은 컬럼 방식 접근 방식은 성능이 크게 향상되고 압축되어 두 접근 방식을 매우 유용하게 사용할 수 있습니다. 많은 기업들이 조직에 단 하나의 데이터베이스 아키텍처 만있는 것이 전체 요구 사항을 지원하지 않는다는 사실을 깨닫기 시작했습니다. 많은 회사가 둘 이상의 데이터베이스 구조를 갖는 개념을 모두 구현하고 있습니다.
