가정하자 나는 웹 사이트가 그 데이터베이스에 대한 하나 개의 테이블이 다음은 어느 데이터베이스 설계가 SQL 쿼리 비용이 적습니까?
TABLE_NAME의 된 table_1와 속성 된 table_1 같은 (A1 (기본 키, A6, A5, A4, A3, A2, A7) 및 내 웹 사이트에
있다가 대부분의 트랜잭션에 대해서만 a4, a5, a6 및 a7은 거의 사용되지 않으므로 다음 옵션에서 데이터에 액세스하는 더 나은 설계 방법이 무엇인지 알고 싶습니다.A) 유지 이 테이블은 그대로이며이 쿼리를 사용하여 table_1의 a1, a2, a3을 선택합니다.
B), A6, A5, A4, A2, A3) 및 table_2 (A1 2 별표 표 (A1 만들기 A7)
저비용 또는로드 데이터베이스를 approch?
(a1, a2, a3)에 대한 읽기 쿼리의 경우, "b"는 (현저하게) 저렴합니다. 두 테이블 사이
그러나 (A4, A6, A5, A7) 경우 다른 모든 것들의 경우, 널 (null)의 대부분, 제외 최악이고, 당신이 사용 (1> 0,1) 카디널리티 (즉 : table_1의 각 a1에 대해 table_2에있는 a1과 동일한 값을 가진 튜플이 0 개 또는 1 개 존재하며 물론 table_2의 a1의 모든 값이 table_1에 있습니다.
어쨌든, 내가 말했듯이, 가능한 이점은 복잡성, 유지 관리 문제 및 효율성 감소 (삽입 및 두 테이블의 데이터가 필요할 때)에 비해 최소화됩니다.
내가 너라면, 나는 "a"레이아웃을 의심 할 여지없이 선택할 것입니다.
B는 A보다 비용이 적게 듭니다. A 옵션을 선택하면 a4, a5, a6, a7 공간을 낭비하게됩니다. 그러나 B 옵션을 선택하면 table_1 연결에 대한 외래 키 (a1)를 만들어야합니다. 그리고 귀하의 SQL 쿼리는 저렴 해집니다.
현대의 RDBMS는 그리 중요하지 않습니다. 널 (null)은 매우 잘 처리되고 고정 길이의 텍스트 또는 2 진 파일은 현재 사용하지 않는 것이 좋습니다. 사실, 많은 경우 그것을 피하는 것이 좋습니다. 예를 들어, PostgreSQL * text *에서는 * char * 또는 * varchar *보다 더 권장되며 (길이 제한 varchar가없는 경우에도) 더 효율적으로 사용됩니다. – bitifet