별도의 연관 테이블을 만드는 데 얼마나 엄격합니까?

report_type 열이있는 표가 있고 보고서 유형이 2 개인 경우를 가정 해 보겠습니다. 그들과 함께 report_types 테이블을 생성 한 다음이 테이블에 외래 키를 사용하여 참조 할 가치가 있습니까? 또는 보고서 유형을 해당 열의 문자열로 저장할 수 있습니까?별도의 연관 테이블을 만드는 데 얼마나 엄격합니까?

출처

2010-08-04 ryeguy

당신은의 값이 뭐 필드를 검색 한 후? –

@Joe : 아무 것도 필터링 목적으로 만 사용됩니다. – ryeguy

고려할 사항 : 당신은 미래의 새로운 보고서 유형을 추가 할 가능성이

입니까?
보고서 유형 (예 : 통계 수집 또는 감사)을 참조하는 다른 표가있을 가능성이 있습니까?
GUI 드롭 다운 위젯과 같은 다른 상황에서이 값을 사용 하시겠습니까?
추가 데이터 (예 : 자세한 설명)를 보고서 유형과 연결해야합니까?

나는 지금 테이블을 구축하는 데 과장된 것 같아서 단지 두 개의 행만 가질 수 있습니다. 그리고 솔직히 말해서 Yagni의 신이 당신을 지원할 것입니다. 그러나 제한된 값 집합을 시행 할 코드 룩업 테이블을 이미 가지고 있다면 일관성의 가치도 있습니다.

출처

2010-08-04 11:59:15 APC

길을 확장하려는 계획이있는 경우입니다. 진짜 질문은 여분의 테이블을 만들만한 가치가없는 것인가?

출처

2010-08-04 01:34:31 Chris

언제든지 데이터베이스를 표준화하고 코드를 추상화해야합니다. 그러나 더 많이할수록 시스템에서 "간접적 인"방향으로 나아갈 수 있습니다. 더 나은 질문은 노력의 측면에서 테이블을 정규화 할 때 오버 헤드가 얼마나되는지, 코드를 도로 아래로 리엔지니어링하는 데 드는 비용입니다.

이 예에서는 데이터베이스를 표준화하는 데 시간을 할애 할 만합니다.

출처

2010-08-04 01:41:50 Dylan

나는 정상적으로 데이터를 표준화하는 것이 좋지만, 그렇게하는 것이 많은 이점을 얻지 못할 정도로 간단한 사례라고 생각됩니다. 앞에서 말했듯이 필터링 전용 필드를 사용하므로 데이터 자체에있는 값만 사용해야합니다.

특정 보고서 유형에 대한 레코드가 0 인 것을 사용자가보기 원하면 관련 테이블을 사용하는 것이 좋습니다.

출처

2010-08-04 03:16:49