クイズ: スキーマ設計と標準

데이터 표준을 표준단어 → 표준도메인 → 표준용어 순으로 정하는 이유는?

• 감리 산출물 목록에 그 순서로 명시돼 있어 순서를 바꾸면 지적받기 때문
• 단어와 도메인을 먼저 고정하면 누가 만들어도 같은 이름과 같은 타입·길이가 나와서
• DBMS 의 카탈로그가 그 순서로 참조를 검증하기 때문에
• 모델링 도구가 그 순서로만 정의서를 생성할 수 있기 때문에

복합 인덱스 컬럼 순서에 대한 기본 규칙으로 옳은 것은?

• 등치 조건으로 쓰는 컬럼을 앞에, 범위 조건으로 쓰는 컬럼을 뒤에 둔다
• 테이블 정의서의 컬럼 순서를 그대로 따라 헷갈리지 않게 한다
• 저장 크기가 작은 타입을 앞에 두어 인덱스 페이지를 아낀다
• NULL 이 적은 컬럼을 앞에 두어 스캔 범위를 줄인다

테이블정의서에 '필수 항목'이라고 적었는데 DDL 에 NOT NULL 이 없을 때의 결과는?

• DB 가 정의서와 스키마를 대조해 경고를 남기므로 배포 전에 발견된다
• 제약이 없어 NULL 이 들어가고, 대개 조회 오류나 통계 불일치로 뒤늦게 드러난다
• 애플리케이션의 검증 계층이 막아 주므로 실제 데이터에는 영향이 없다
• 제약 검사가 빠져 삽입이 빨라지는 대신 조회에서 손해를 본다

국내 SI 에서 날짜를 CHAR(8) YYYYMMDD 로 유지하는 관행에 대한 가장 균형 잡힌 판단은?

• 타입 선택은 표준을 따르는 것이 맞으므로 신규는 예외 없이 DATE 로 간다
• 고정길이 비교가 빨라 CHAR(8) 이 DATE 보다 조회 성능이 늘 유리하다
• 연동·이관 지점이 많으면 변환 누락이 조용한 오류가 되므로 '합의' 로 판단해야 한다
• 레거시 DBMS 가 DATE 를 지원하지 않아 어쩔 수 없이 굳어진 관행이다

논리 삭제(DEL_YN)를 쓰는 시스템에서 가장 흔한 사고는?

• 지운 행이 계속 남아 테이블이 커지면서 디스크가 모자라는 것
• 삭제 표시 컬럼의 값이 한쪽으로 치우쳐 인덱스가 무용해지는 것
• 조회 쿼리에서 삭제 조건을 빠뜨려 삭제된 데이터가 화면에 노출되는 것
• 삭제 표시 갱신이 몰리면서 같은 행을 두고 교착 상태가 생기는 것

데이터 이관 시 인덱스를 삭제하고 적재한 뒤 다시 만드는 이유는?

• 인덱스가 이관 데이터를 손상시키기 때문
• INSERT 마다 모든 인덱스가 갱신되어 대량 적재가 크게 느려지기 때문
• 인덱스가 있으면 CSV 적재가 불가능하기 때문
• 인덱스는 이관 후 자동으로 재생성되기 때문

테이블정의서를 DB 메타데이터에서 생성하도록 만드는 실무적 이점은?

• 문서를 손으로 적는 시간이 줄어 산출물 작성 공수가 절약된다
• 정의서 생성 과정에서 통계가 갱신되어 조회 성능이 함께 좋아진다
• 문서와 실제 스키마가 어긋나지 않고, 사람은 설명만 관리하면 된다
• 자동 생성 산출물은 감리에서 신뢰도가 높아 평가에 유리하다