데이터베이스에있는 200 개의 테이블이 너무 많습니까?

Question

분명히이 질문은 더 많은 정보 없이는 대답 할 수 없으므로 확장하겠습니다.

임 건물 약 1000 상점

그들은 제품의 13 가지 주요 범주로 구분되어있는 저장하는 데이터베이스.

13 개

그 주요 카테고리 각각에 대해 4 또는 5 서브 카테고리

그 4-5 (총 65)이 각각의하면이 약 4 또는 5 자신.

모든 단일 부모와 그 직접 자식에 대해 하나의 테이블을 만드는 것입니다. 그리고 각 자녀와 자녀를위한 테이블.

논리의 측면에서, 내 프로그래밍 요구 사항을 충족시킬 것입니다,하지만이 경우에는 많은 테이블을 가지고 있고 그것을 할 더 좋은 방법이 있다면 완전히 정통 아닌지 궁금합니다.

쿼리 할 때 많은 테이블이 시스템에 과부하/지연을 발생시키는 지 궁금합니다.

2 개의 테이블에서 전체 작업을 수행 할 수있었습니다. 여기서는 각 카테고리에 parent_id를 할당했지만 시각적 인 관점에서는 매우 체계적이거나 계층 적으로 보이지 않았습니다. 반면 완벽한 트리와 같습니다.

Answer 1

적절한 인덱싱을 사용하여 관계형 데이터베이스 구조 (일대 다 관계 또는 다 대다 관계 포함)를 사용하십시오. 각 카테고리에 대해 별도의 테이블을 만들면 논리적으로 이해가되지 않습니다. 이것이 관계형 데이터베이스가 개발 된 이유입니다.

당신의 솔루션은 효과가 있지만 데이터 적으로는 좋지 않습니다.

는

TABLE categories: 
id title parent_id(NULL) 

이 그럼 당신은 PHP의 일부 재귀를 사용하여이에게서 얻는 결과를 정렬

데이터베이스 구조

처럼 더 specefique를 얻으려면.

Answer 2

가장 중요한 정보를 제공하지 않았기 때문에이 질문에 답할 수 없습니다.로드하십시오. 얼마나 많은 사용자가이 데이터베이스를 사용할 것입니까? 마찬가지로 인프라를 호스팅하는 데 어떤 회사를 사용하고 있습니까?

또한 잘못 작성된 코드는 성능이 좋지 않은 데이터베이스가됩니다.

그 외에도 각 페이지마다 작은 타이밍 스크립트를 만드십시오. 각 쿼리의 소요 시간을 결정한 다음 얼마나 많은 사용자가 기대 하는지를 곱하십시오. 초당 400 회의 쿼리가있을 것으로 예상된다면 코드를 작성하는 방법과 인프라를 호스팅하는 데 사용하는 사람과 같은 요소가 매우 중요합니다.

Answer 3

모든 테이블이 동일한 필드 또는 대부분 필드가 같고 동일한 필드 (즉, 제품)를 나타내는 경우 두 테이블 만 사용하는 솔루션이이 데이터베이스를 디자인하는보다 표준적인 방법입니다. 하나의 테이블은 모든 제품과 해당 카테고리 (가장 구체적인 카테고리)를 나열하고 다른 테이블은 카테고리를 나열합니다. 이 표에 나오는 계층 적 정보를 다루는 다양한 방법에 대한 설명은 this question을 참조하십시오. nested set model도 여기에 사용자의 요구를 충족시킬 수 있습니다.(이 질문에 대해서는 질문을하지 않은 사람이 필요하기 때문에 논의되지 않았습니다.) 선택한 모델에 따라 모델을 구현하기 위해 세 번째 테이블을 추가해야 할 수도 있습니다.

Answer 4

몇 가지 고려 사항 : 멀티 테이블 시나리오에서

, 당신은 등 성장 제품/카테고리로 점점 더 많은 테이블을 계속 추가 할 필요가 있지만, 빠른 조회를 유지 (낮은 기록의 전체 테이블 스캔)합니다 그리고 클리너와 관계를 더 정 확하게 쿼리합니다.

일반적으로 자체 조인을 사용하여 데이터를 가져 오는 두 테이블 시나리오에서는 모든 데이터가 이러한 몇 가지 테이블에 있기 때문에 조회가 느려질 수 있습니다. 또한 개인적인 경험을 통해, 특히 n-level 부모 - 자식 관계가 될 때, 같은 테이블에서 많은 코드와 관계로 유지하는 것이 고통입니다. 오라클은 이러한 상황에 대한 SQL 문을 구문 분석하여 쿼리를 쉽게 처리 할 수 ​​있습니다. 그러나 MySQL에는 이들이 없습니다.

내가 처음이라면 모든 것이 고려 될 것입니다. - 부모 관계지만, 대부분은 원자 적으로 유지합니다. (btw, 나는 (기존의) MySQL 데이터베이스를 400+ 테이블과 함께 작업 했으므로 200 개의 홀수 테이블을 가지고 있어야한다고 생각한다.)

Answer 5

200 테이블은 당신이 설명하는 문제에 대해 과잉이다. 상점에 대한 데이터를 하나의 테이블에 저장하고, 카테고리에 대한 데이터를 다른 테이블에 저장하고, 하위 카테고리에 대한 데이터를 세 번째 테이블에 저장할 수 있습니다. 마지막으로 네 번째 테이블의 하위 카테고리에 대한 테이블을 저장할 수 있습니다. 그런 다음 주어진 상점 및 주어진 서브 서브 카테고리와 관련된 데이터를 다섯 x 째 테이블에 저장할 수 있습니다.

외래 키/기본 키 참조 정의를 사용하여이 테이블의 행을 다른 테이블의 행에 연결하고 join을 사용하여 필요에 따라 데이터를 결합합니다.

훨씬 간단하고 성능이 뛰어날뿐만 아니라 앞으로 더 많은 기능이 추가 될 예정입니다. 데이터베이스의 구조를 변경하지 않고 새 상점을 추가 할 수 있습니다. 뿐만 아니라 데이터베이스를 구축 한 후에도 데이터에 대한 다양한 쿼리를 수행 할 수 있습니다.

다양한 방식으로 동일한 데이터를 활용하는 것이 실제로 데이터베이스에 관한 것입니다. 구조로 인해 새로운 방식으로 데이터를 악용하려고 할 때마다 새 프로그램을 작성해야합니다. 고전적인 디자인을 사용하면 SQL에 쿼리를 작성하면됩니다.

그건 그렇고, 나는 그것에 400 테이블과 같은 것을 가지고 데이터베이스를 보았다. 그러나이 데이터베이스는 중견 대학의 모든 관리 데이터를 관리했습니다. 학생, 코스, 등록 및 성적에서 동창 기부금, 고교 성적표, 스포츠 경기 및 주차 공간에 이르기까지 모든 것. 당신의 문제는 거의 복잡하지 않습니다.