관계 테이블이 실제로 필요합니까?

관계 테이블에는 주로 두 개의 열, 즉 IDTABLE1 및 IDTABLE2이 포함됩니다.관계 테이블이 실제로 필요합니까?

관계 테이블간에 변경되는 것으로 보이는 것은이 두 열의 이름과 테이블 이름뿐입니다.
가 TABLE_NAME이 IDTABLE1는, IDTABLE2는 다음 모든 관계에 대한이 테이블을 사용 : 우리가 하나 개의 테이블 Relationships을 작성하고이 테이블에 우리는 3 열을 배치하면

은 더 나은 것입니까?

웹/데스크톱 응용 프로그램 개발에 적합합니까? 이것의 단점은 무엇입니까?

참고 :
의견을 보내 주셔서 감사합니다. 감사합니다.
하지만 조금 지나치게 생각하고 있습니다. 모든 솔루션은 한 지점까지 작동합니다.
데이터 저장 단순 텍스트 파일이 특정 시점까지 Excel보다 SQL Server보다 MS Access가 더 좋습니다 ...
솔직히 말해서이 솔루션이 왜 그런지에 대해서는 언급하지 않았습니다. 소규모 프로젝트 (DB 크기가 몇 GB 인 경우)에 적합하지 않습니다.

출처

2011-02-08 This is it

한 걸음 더 나아가서 TABLE_NAME, ID, COLUMN_NAME, VALUE의 4 개의 열이있는 하나의 거대한 테이블을 만들어보세요. –

@Martinho Fernandes - 확실히 세 개의 열만 있으면됩니다. ID와 column_name은 밑줄을 사용하여 함께 연결할 수 있습니다. – Paddy

@Paddy : Nah, 마이크로 최적화 일 것입니다. 그리고 그것은 ID에서 밑줄을 사용하지 못하게합니다. –

나쁜 아이디어.

IDTABLE1에 어떤 테이블에서든지 id을 포함시킬 수있는 경우 외래 키를 적용하는 방법은 무엇입니까?

전혀 관계없는 행을 가져 오기 위해 불필요한 IO를로드하지 않고 조인 할 때 허용되는 성능을 얻으려면 선행 열 TABLE_NAME을 가진 복합 인덱스가 필요합니다. 기본적으로 결국 테이블을 섹션으로 분할합니다.

분명히이 가상 파티션을 사용하더라도 테이블/인덱스에 많은 공간을 낭비하게됩니다. 각 행의 테이블 이름을 반복하면됩니다.

출처

2011-02-08 11:49:25

그런 성가신 접근법에는 실제 이점이 없습니다. +1 – alex

테이블의 괴물 일 것입니다. 그것은 또한 성 가실 것이다. 성능면에서 볼 때 그러한 테이블은 좋은 생각이 아닙니다. 또한 외래 키는 이러한 테이블에 추가 할 수 없습니다. 나는 그런 해결책에 많은 이점을 실제로 볼 수 없다.

출처

2011-02-08 11:49:31 alex

좋은 답과 관계형 테이블 디자인을 사용하면 복제 또는 고아 레코드를 방지하기가 정말 어려울 것입니다. – futile

또 다른 장점 : 관계 당 몇 가지 추가 데이터가 필요하게되면 결국 망가집니다. –

또한 이러한 테이블을 업데이트하는 것은 특히 수십만 개의 항목이있는 악몽입니다. – alex

2 개의 ID 입력란 만 저장하면 큰 문제가되지 않습니까? StudentID가 & CourseID 인 StudentCourse (또는 더 나은 아직 등록) 테이블이 있지만 모든 학생이 수업 첫날에 등록하지 않기 때문에 EnrollmentDate는이 테이블에도 포함되지 않습니다. 대부분의 레코드가 null이되는 이미 비 대한 테이블에이 열을 추가하는 것은 좋지 않은 것 같습니다.

단일 테이블의 이점은 응용 프로그램이 사용자/관리자가 데이터를 사용하여 이러한 관계를 만들 수 있다는 요구 사항 일 수 있습니다 (단일 조회 또는 참조 목록 테이블과 비슷 함). 표를 참조하여 사용자 생성 참조를 처리하십시오. 동적 쿼리가 필요할 수도 있습니다. 이러한 동적 데이터 구조 요구 사항을 필요로하는 응용 프로그램은 스키마가 없거나 nosql 데이터베이스에 더 적합 할 수 있습니다.

출처

2014-05-06 22:21:53 JeffO

관계 테이블이 실제로 필요합니까?

답변

관련 문제