이것은 데이터베이스 디자인 질문입니다.큰 테이블 또는 여러 개의 개별 테이블? (데이터베이스 디자인 질문)
인보이스 웹 응용 프로그램을 만들려는 경우 인보이스에 많은 항목이 포함될 수 있으며 각 사용자는 저장할 수 있고 인보이스 항목에 추가하도록 선택할 수있는 제품 항목 목록을 보유 할 수 있습니다.
내 질문은 다음과 같습니다.
1. 하나의 테이블 아래에서 내 응용 프로그램을 사용하는 모든 사용자에 대한 모든 제품 인벤토리를 저장해야합니까? 또는 각 사용자에 대해 별도의 제품 인벤토리 테이블을 만들었습니까?
2. 이것도 가능합니까?
1 개의 테이블이 더 쉽지만이 단일 테이블이 커지면 어떻게 될까요? (기본 키 INT).
사용자 당 표는 나쁜 아이디어입니다. 모든 인벤토리를 userid의 키가있는 단일 테이블에 보관하십시오. 이 테이블은 어떤 산업 강도의 DBMS에서도 문제가 될 정도로 꽤 커야합니다 (이러한 질문을하기 전에 수천만 개의 행이 생길 때까지 기다려야합니다).
사용자가 가장 자주 인벤토리에 액세스하는 경우 userid을 클러스터 된 키의 첫 번째 열로 지정하여 이러한 쿼리의 속도를 높일 수 있으므로 사용자 당 인벤토리가 디스크에 함께 뭉치 게됩니다. 다시 한 번 말하지만 실제로 성능 저하가 관찰 될 때까지는 이러한 문제를 숙고하지 마십시오.
제품 사용자가 생성 되었습니까?
어쨌든 제품에 대한 테이블 하나와 사용자에 대한 테이블 하나가 있다고 생각합니다. 제품의 출처에 따라 (즉, 사용자가 독점적이거나 사용자가로드 할 수 있거나 여러 사용자가 액세스 할 수있는 경우) 사용자를 제품에 매핑하는 테이블이있을 수 있습니다. 제품이 실제로 특정 사용자에게만 독점적 인 경우 제품 레코드와 함께 사용자 ID를 저장하는 것으로 충분합니다.
처음에는 테이블 크기에 대해 걱정하지 마십시오. SQL Server는 강력한 데이터베이스 도구입니다. 올바른 데이터베이스 정규화 및 적절한 인덱싱 만 사용하십시오.
테이블이 커지면 서버의 설정과 레이아웃이 중요해질뿐만 아니라 인덱스 선택 및 쿼리 작성 방법이 중요해질 것입니다. 그러나 수백만 개의 행 ()이 있다고 예상하지 않는 한, 하나의 테이블에 대해 너무 많은 행을 사용하지 않아도됩니다. 엄지 손가락의
일반적인 규칙은 테이블 가 데이터를 포함하지만, 및 자신의 데이터하지 해야한다는 것입니다. 테이블에 누가 데이터가 있는지를 알기 시작하면 2 번째 범주로 나아갈 가능성이 있으며 백업하고 자신이하는 일을 고려해야합니다.
각 사용자가 소유/관리하는 고유 한 제품 세트를 가지고있는 경우 단일 테이블을 나중에 분할 할 수 있습니다. 다른 사람들이 제안했듯이 수천만 가지 제품을 기대하지 않으면 성능에 대해 걱정할 필요가 없습니다.
단일 테이블로 시작하는 것이 좋습니다. 제품 스키마가 각 사용자마다 동일하면 매우 간단하고 효율적인 디자인입니다.
그러나 다른 사용자와 관련된 제품에 다른 스키마가 필요한 경우 매우 희소 한 테이블 (모든 레코드의 빈/NULL 필드가 많아 모든 사람의 성능에 영향을 미침)이 생길 수 있습니다.
일반적인 접근 방법은 제품 ID, 속성 이름 및 속성 값이라는 세 개의 열이있는 EAV (Entity-Attribute-Value) 테이블입니다. 이것은 완전히 동적 인 솔루션이며 매우 간단합니다. 그러나 선언적 constarint를 구현하는 것을 어렵게 만듭니다.
필자가 선호하는 동적 스키마는 정적/항상 필수 필드를 영구/테이블 스키마의 일부로 만드는 것입니다. 동적 부분은 XML 필드로 생성되고 XML 스키마 (또는 컬렉션)에 의해 제약 될 수 있습니다. 데이터 무결성은 이러한 방식으로 잘 적용될 수 있으며 여분의 비트에 대해 단일 필드 만 필요합니다.
옵션 2에 문제가 있습니다. Joe Celko는이 디자인 결함을 table splitting으로 언급합니다. Chris Date는이를 위반하여 the principle of orthogonal design이라고 말합니다.
안녕하세요 1 스키마입니다, 1 스키마를 선호합니다! 모든 소유자가 1 명 (쉽게 확장 가능) 테이블 구조가 모든 사용자에게 동일합니다! – 001