가능한 적은 수의 테이블로 데이터베이스를 작성해야합니까?

최소 개수의 테이블로 데이터베이스 구조를 만들어야합니까?

모든 것이 한 곳에 머 무르거나 더 많은 테이블을 갖도록 설계되어야합니까?

어쨌든 어떤 영향을 미칩니 까?

내 친구가 mediaWiki에서 일부 데이터베이스 구조를 수정했기 때문에이 질문을하고 있습니다. 결국, 그는 20 개의 테이블 대신 8 개만 사용했으며,이를 수행하는 데 8 개월이 걸렸습니다 (대학 과제).

편집하다

나는 대답이 다음과 같이 결론을 내린다. 이 경우 비정규 화가 도움이 될 수 있습니다.

답변을 주셔서 감사합니다.

테이블 수를 무시 하십시오. 디자인을 올바르게 만드는 것에 대해 더 걱정 하십시오. 주요 관심사가 테이블 수량 인 경우 데이터베이스 시스템을 설계하지 않아야합니다.

친구가 8 개의 테이블 만 필요로하고 시스템이 제대로 작동하면 8이 올바른 숫자이고 나머지 12는 자신이하는 일에 필요하지 않을 수 있습니다.

가능한 예외는 테이블 번호에 대한 제한이있는 특수한 환경 일 수 있지만 머리 꼭대기에서 그러한 시스템의 구체적인 예를 생각할 수는 없습니다.

데이터베이스에는 필요한만큼 정확하게 테이블이 있어야합니다. 더 이상은 아닙니다.

데이터베이스 테이블은 클래스와 마찬가지로 단일 책임 원칙을 준수해야합니다. 각 테이블은 시작하기 위해 하나 이상의 관련 데이터 그룹을 처리해야합니다. 성능 자체는 테이블 자체가 더 작기 때문에 전체 짐승을 더 쉽게 관리 할 수 ​​있습니다. 테이블이 작을수록 검색 및 조인이 더 빠르기 때문에 성능도 향상됩니다.

클래스 수에 대해 걱정하는 것보다 테이블 수에 대해 걱정하지 마십시오. 전혀 걱정하지 마십시오 . 차지하는 공간이 아니라 깨끗하고 읽기 쉬운 코드를 만드는 데 중점을 둡니다. 더 나은 제품을 만들기 위해 적극적으로 리팩토링하십시오. 데이터베이스도 마찬가지입니다! 다른 테이블에 있거나 필요하지 않은 열을 볼 수 있습니다. 어떤 쿼리가 가장 오래 걸리고 왜 발생하는지 확인하고 실제로 문제가있는 경우 이러한 문제를 해결하기위한 프로필입니다.

비즈니스 애플리케이션의 프로덕션 데이터베이스에는 수백 또는 수천 개의 테이블이 포함될 수 있습니다. 비즈니스 요구 사항에 필요한 수의 테이블이 필요합니다. 더 적은 수의 테이블을 위해 테이블 ​​수를 줄이려고하면 일반적으로 쿼리하기 어렵고 데이터 무결성 문제가 있으며 정규화 된 데이터베이스보다 maintian에 훨씬 더 어려운 데이터베이스가 생성됩니다.

비정규 화가 필요한 경우가 있습니다. 이것은 자신이하는 일과 그 이유를 정확히 아는 사람 만 수행해야합니다. denomalizing은 매우 쉽게 수행 할 수 있으므로 데이터베이스 전문가 나 수년간의 데이터베이스 경험이있는 선임 응용 프로그램 개발자 만 수행해야합니다. 경험이없는 사람은 자신이 디자인 한 데이터베이스에서 최소한 세 번째 정상적인 형태에 도달하려고 노력해야합니다 (데이터웨어 하우징을 수행하지 않는 한, 경험이없는 사람을 고용하지 않는 영역).

사람들이 조인이 비싸서 테이블을 줄이려고 할 때 일반적으로 중요한 인덱스가 누락되었거나 큰 다중 열 자연 키를 사용하는 데이터베이스를 알지 못하거나 잘못 설계했습니다. 관계형 데이터베이스는 조인을 사용하도록 설계되었으며 FK가 올바르게 인덱싱되고 작은 필드를 사용하여 조인하는 경우 조인이 매우 효율적일 수 있습니다 (정수가 가장 효율적 임). 테라 바이트 규모의 데이터베이스를 보유한 대기업은 어떻게 든 우수한 성능을 얻고 조인을 사용할 수 있습니다.

심각한 데이터베이스 디자이너는 더 적은 수의 테이블을 원하기 때문에 테이블 수를 줄이려고 시도하지 않습니다. 데이터가 더 이상 필요하지 않거나 다른 방법으로는 해결할 수없는 성능 문제가 있기 때문에 테이블 수를 줄입니다 (테이블 을 비정규화할 때 데이터에 광범위한 위험 을 감수 하기 전에 시도 할 방법이 많이 있습니다) .

데이터베이스의 모든 필드는 테이블 이름, 열 이름, 기본 키 및 값의 조합으로 정의되므로 항상이를 저장하는 단일 테이블로 비정규 화하여 테이블 수를 줄일 수 있습니다. 매우 유용하지는 않지만 완전히 가능합니다.

테이블은 데이터 처리 문제를 해결하는 추상 계층입니다. 이것이 그들이 만들어지는 이유입니다. 나는 농담을했지만 모든 데이터 세트를 하나의 마스터 테이블로 줄일 수 있다는 것을 이해하면 테이블이 무언가를 가져 오기 때문에하지 말아야하는 이유를 즉시 지적합니다. 개념적 수준에서는 직렬화 된 데이터보다 사람이 이해하기 쉬운 구조를 제공합니다. 중간 수준에서는 정규화 개념을 가져옵니다. 즉, 중복 된 데이터를 저장하지 않고 여러 위치에서 무언가를 변경하지 않고 변경 사항을 단일 지점에 제공합니다. 기술 수준의 데이터베이스에는 데이터와 관련하여 수행하려는 대부분의 도구와 수많은 도구가 포함되어 있으며이를 구현하고 직접 테스트하는 것보다 더 많이 테스트했습니다. 데이터 형식, 기본값, 사용자 권한, 인덱스, 외래 키 제약 조건 등을 생각하십시오. 그것은 많은 최적화되고 디버깅 된 테스트되었습니다. (완벽하지는 않지만 여전히)

데이터베이스는 도구이므로 도구 사용 방법을 결정하는 것이 가장 중요합니다. 테이블 수는 중요하지 않습니다. 최소화는 항상 가능하지만 이익을 버리는 비용이 든다. (정규화에 대해 더 많이 읽으면 비정규 화에 대한 몇 가지 사례를 보게 될 것입니다. 그러나 맹목적으로 테이블 수를 줄이는 것이 아니라 올바른 결정에 관한 것입니다.)

올바른 수의 테이블을 사용해야합니다 . 이론적으로 전체 데이터베이스를 비정규 화하여 단일 테이블 테이블로 수행 할 수 있지만 데이터베이스를 사용할 수 없습니다. 친구가 손에 너무 많은 시간을 보낸 것 같습니다.

최소한의 테이블 수를 갖는 것이 매우 독특한 목표입니다.

확실히 20 개의 테이블에서 8 개의 스키마로 스키마를 줄이는 것이 좋은 방법 일 수 있습니다 (잘 수행하면 조인을 줄이고 성능을 향상 시키거나 사용하지 않는 열을 제거하는 등) 할 수 있지만 앞으로도 이해하고 향상시키기가 더 어려워 질 수 있습니다.

다른 방법으로 생각하면 정규화가 좋은 것이라고 생각합니까? 정규화는 일반적으로 더 많은 수의 테이블로 이어지지 만보다 유지 관리 가능한 솔루션, 데이터 중복 감소 및 더 쉬운 데이터 관리로 이어집니다.

물론 비정규 화 된 데이터베이스가 제대로 설계되었다고 가정하면 성능이 저하 될 수도 있습니다.

궁극적으로 이러한 영역의 요구 사항에 대해 생각해야하지만 기본 시작 위치로 합리적인 수준의 정규화를 수행 한 다음 더 적은 수의 테이블이 솔루션이 될 수있는 특정 문제를 일으키는 지 살펴보십시오.

숫자는 중요하지 않습니다. 디자인입니다. 일부 시스템을 살펴보십시오. Magento, PHPBB 등. 그들은 시스템에 수십 개의 테이블을 가지고 있으며 잘 작동합니다.

정규화 및 성능에 대한 우려와 함께 "다른 테이블이 필요합니다"를 응용 프로그램의 범위를 관리하는 방법으로 사용할 수 있습니다. 이 기능을 사용하려면 새로운 테이블과 업그레이드, 설계, 빌드, 테스트, 관리 및 기타 모든 코딩에 대한 모든 시간, 에너지 및 노력이 필요합니다. 기존 테이블에 5 개의 필드를 추가하는 것이 5 열 테이블보다 훨씬 쉽습니다.

테이블 생성을 최소화하려고 데이터베이스를 설계하면 갑작스러운 어려움을 겪게 될 것입니다.

데이터베이스 디자인을 만들 때 테이블 수를 최우선으로 생각해서는 안됩니다. 논리적이고 관계 적으로 필요한 곳에 물건을 두십시오.

모든 비즈니스 의도와 목적을 위해 함께 유지해야하는 데이터를 여러 테이블로 분할하기로 선택한 경우 (즉, 데이터베이스를 정규화해야 함) 테이블 수가 중요하고 성능에 큰 영향을 줄 수 있다고 생각합니다. 일반적으로 이렇게하면 필요한 모든 데이터를 가져오고 이와 같이 구조화 된 충분히 큰 테이블에 대해 성능을 빠르게 떨어 뜨리기 위해 JOIN 작업 (또는 비 SQL에 해당)을 수행해야합니다.

자세한 내용은 다루지 않겠지 만 테이블 수가 성능에 영향을 줄 수 있다는 사실은 Cassandra, Mongo 및 Google BigTable (sic!)과 같은 SQL 데이터베이스가 발명되지 않은 이유 중 하나라고 생각합니다. 그것이 또한 데이터의 비정규 화를 장려하고 (따라서 많은 테이블 / 컬렉션 등을 피하는 등) 이유입니다.

문서를 여러 개의 "테이블"또는 "입력 유형"으로 나누는 것을 장려하거나 쉽게 촉진하지 않는 Apache 's Solr과 같은 검색 서버에 대해서도 마찬가지입니다. 색인을 작성하려는 모든 문서 유형에 적용합니다 (따라서 JOIN과 유사한 조작을 수행하지 않아도 됨).

나는 스키마에 x 테이블이 있다는 단순한 사실이 항상 x / 2 테이블이있는 스키마보다 느리게 만들 것이라고 말하지는 않지만 결과적으로 속도가 느려질 수있는 특정 컨텍스트가 있습니다. 모든 해당 테이블의 데이터를 집계하는 데 추가 작업이 필요했습니다. 계속해서 "테이블 수와 데이터의 정규화가 성능에 미치는 영향은 없다"고해도 괜찮습니다.

밥 삼촌은 More가 더 단순하다고 주장 할 것입니다.

http://c2.com/cgi/wiki?FearOfAddingTables를 참조하십시오 .

"테이블을 추가하면 좋은 디자인이 일반적으로 단순화됩니다"

나는 거의 모든 엔티티가 다 대다이며 더 많은 테이블이 필요하다고 생각합니다.

대륙 코드가 포함 된 국가 테이블을 작성하십시오. 아, 당신은 실제로 8 대륙 횡단 국가가 있기 때문에 할 수 없습니다. 통화와 동일합니다. 파나마는 두 가지를 사용합니다.

그런 다음 대답은 예입니다.

그러나 "최소"테이블 수의 진정한 의미가 무엇인지에 따라 달라집니다.

예를 들어 (반예).

다음 물체가 있다면

1. 사용자
2. 고객

둘 다 동일한 상태 (필드)를 공유하며 보안 제한이 없으므로 단일 테이블을 수행하는 것이 더 적합합니다.

1. table_persons

오히려 두 개의 다른 테이블

1. table_users
2. table_customers

단점은 table_persons보다 새 필드 (type_of_person)를 추가해야합니다.

다른 실수 (실제로 필요하지 않은 경우 실수)는 테이블을 "분할"하는 것으로, 단일 테이블을 두 개로 분리합니다.

1. table_persons

두 테이블에서

1. table_info_persons
2. table_extra_info_persons

두 쿼리를 조인하도록 일부 쿼리를 강요하고 있기 때문에 좋지 않습니다.