좋은 데이터베이스 명세는 소프트웨어 구현의 복잡성을 줄이고 통신 비용을 줄이는 데 도움을 줍니다.
1. 창고 건설의 철칙
- | 철의 법칙 | 레벨 | 말 | 문자 집합 | UTF-8을 사용하세요. 이모지가 저장된다면 utf8mb4를 사용해 저장하세요. | 강제로 |
| | 정렬 규칙 | utf8_general_ci | 강제로 | |
2. 표 구성의 철칙
- | 철의 법칙 | 레벨 | 말 | 주석 | 필드 주석을 꼭 넣으세요. | 강제로 |
| | 인코딩하 | UTF-8을 사용하세요. 이모지가 저장된다면 utf8mb4를 사용해 저장하세요. | 강제로 |
| | 장이 개념적인가 여부 | 이름은 is_xx로 명명되어야 하며, 데이터 타입은 부호 없는 tinyint(1 yes, 0 no)입니다. 예를 들어 is_deleted(1 delete, 0 not deleted). | 강제로 | 음수가 아닌 필드는 부호가 없어야 합니다 | 테이블 이름, 필드 이름 | 소문자, 밑줄, 숫자만 사용할 수 있습니다; 밑줄이나 숫자로 시작하는 것은 금지되어 있습니다; 두 밑줄(underscore) 사이에는 숫자만 허용되며; 예약어를 비활성화하고; 테이블 이름에서 복수 명사 사용은 금지되어 있습니다. | 강제로 |
| | 데이터베이스 이름과 테이블 이름의 명칭 | 데이터베이스 이름은 애플리케이션 이름과 일치해야 하며, 테이블 이름은 테이블의 비즈니스 Name_Role로 명명되어야 합니다. | 강제로 |
| | 인덱스 명칭 | 주요 키 인덱스는 필드 이름을 사용pk_; 필드명이 uk_ 고유 인덱스; 일반 인덱스는 idx_ 필드 이름을 사용합니다. | 강제로 | pk_ 기본 키이며; uk_ 고유 키입니다; idx_ 지인입니다 | 십진법 | 데이터 타입은 십진수이며, float와 double의 사용은 금지되어 있으며, float와 double은 정밀도 손실이 있습니다. 저장된 데이터 범위가 십진수 범위를 초과하면 데이터를 정수와 소수점으로 나누어 별도로 저장하는 것이 권장됩니다. | 강제로 |
| | 바르차르 유형 | varchar는 변수 긴 문자열이며, 저장 공간이 미리 할당되지 않으며, 길이가 5000자를 초과하지 않아야 합니다. 길이가 5000자를 초과하면 텍스트를 적용합니다(별도의 테이블을 만들고 기본 키를 사용해 다른 필드의 인덱싱 효율에 영향을 주지 않도록 하세요). | 강제로 |
| | 테이블 이름에는 반드시 세 개의 필드가 있어야 합니다 | id(데이터 타입은 부호 없는 bigint, 단일 테이블 증가, 스텝 크기는 1), gmt_create, gmt_modified(활성 생성 시간, 수동 업데이트 시간, 데이터 타입은 datetime). | 강제로 |
| | 필드 중복성 | 필드는 적절한 중복을 허용하지만, 데이터 일관성을 고려해야 하며, 중복 필드는 1) 드문 수정이 있어야 합니다; 2) 아주 긴 필드가 아니라, 텍스트 필드는 말할 것도 없습니다. | 추천 |
| | 데이터베이스와 테이블을 나누세요 | 파티셔닝은 단일 테이블의 행 수가 500만 행을 초과하거나 단일 테이블의 용량이 2GB를 초과할 때만 권장됩니다. | 추천 | |
적절한 문자 저장 시간을 설정하면 데이터베이스 테이블 공간과 인덱스 저장 공간을 절약할 뿐만 아니라, 더 중요한 것은 검색 속도를 향상시킵니다.
3. 지수 철법칙 확립
- | 철의 법칙 | 레벨 | 말 | 고유 인덱스 | 사업 내에서 고유한 특성을 가진 필드는 여러 필드의 조합이라 해도 고유하게 색인되어야 합니다. 고유 인덱스가 삽입 속도에 영향을 주긴 하지만, 이 손실은 무시할 수 없으며, 쿼리 속도를 크게 향상시킵니다. 또한, 애플리케이션 계층이 매우 완벽한 체크 제어를 가지고 있더라도, 고유 인덱스가 없는 한, 머피의 법칙에 따르면 불가피한 데이터가 생성됩니다. | 강제로 |
| | 가입 | 세 개 이상의 테이블은 조인을 금지하고, 조인이 필요한 필드는 허용되며, 데이터 타입은 일관되어야 합니다; 쿼리에 여러 테이블이 연관되어 있을 때, 관련 필드에 인덱스가 있어야 하는지 확인하세요. 더블 테이블 조인이 있더라도 테이블 인덱싱과 SQL 성능에 주의하세요. | 강제로 |
| | 바차필드 | 인덱스 길이는 지정되어야 하며, 모든 필드를 인덱싱할 필요는 없고 실제 텍스트 구분에 따라 인덱스 길이를 결정하면 됩니다. 인덱스 길이와 구별은 모순 쌍이며, 일반적으로 문자열 유형 데이터의 경우 길이 20의 인덱스는 90% 이상의 구별 정도를 가지며, 이는 카운트(왼쪽(열명, 인덱스 길이))/카운트(*)의 차별도에 의해 결정됩니다. | 강제로 |
| | 페이지 검색에서는 흐림 처리가 금지되어 있습니다 | 페이지 검색은 흐림 처리나 완전 흐림을 금지합니다. 필요하다면 검색 엔진에서 해결해 주세요. 금지 이유: 인덱스 파일은 B-트리의 가장 왼쪽 접두사 일치 속성을 가지고 있으며, 왼쪽 값이 결정되지 않으면 이 인덱스를 사용할 수 없습니다. | 강제로 |
| | 순서는 | 만약 상황별 순서가 있다면, 지수의 질서에 주목하세요. 순서 의 마지막 필드는 결합된 인덱스의 일부이며, file_sort을 피하고 쿼리 성능에 영향을 주기 위해 인덱스 조합 순서의 끝에 배치됩니다. 예시: a=는 어디인가요? 그리고 b=? 순서는 c; 인덱스는 a_b_c 방식으로 구성되어야 합니다; 반례: 인덱스에 범위 조회가 있을 경우, 인덱스 질서를 사용할 수 없으며, 예를 들어 a>10 order by b; 인덱스 a_b는 정렬할 수 없습니다. | 추천 | |
4. SQL 철칙 작성
- | 철의 법칙 | 레벨 | 말 | 카운트(*) | count(column name)나 count(constant) 대신 count(constant)를 사용하지 마세요. 이 문법은 SQL92에서 정의된 표준 행 개수를 나타내며, 데이터베이스와 NULL과 NULL과 무관합니다. count(*)는 NULL 값을 가진 행을 세지만, count(column name)는 이 열이 NULL인 행을 카운트하지 않습니다. | 강제로 |
| | 백작(구별된 고안) | NULL을 제외한 열의 고유 행 수를 세는 것입니다. count(distinct col1, col2)에서 한 열이 모두 NULL이라면, 다른 열이 다른 값을 가졌더라도 0을 반환한다는 점에 유의하세요. | 강제로 |
| | sum(col) | 열의 값이 모두 NULL일 때, count(col)은 0을 반환하지만, sum(col)은 NULL을 반환하므로 sum()를 사용할 때는 NPE 문제를 인지해야 합니다. NPE 문제는 다음과 같은 방법으로 피할 수 있습니다: if(isnull(sum(g)), 0, sum(g)) | 강제로 |
| | isnull | isnull()를 사용해 NULL 값인지 확인하세요. NULL은 어떤 값과 비교해 NULL입니다. | 강제로 |
| | 페이지네이션 쿼리 로직 | 만약 카운트가 0이라면, 이후 페이지네이션 문장을 실행하지 않기 위해 직접 반환해야 합니다. | 강제로 |
| | 외부 키와 폭포 | 외래 키 사용과 캐스케이드 처리는 금지되며, 모든 외래 키 개념은 애플리케이션 계층에서 해결되어야 합니다. 이유는 외래 키와 캐스케이드는 분산된 고동시성 클러스터에 적합하지 않고, 캐스케이드 업데이트는 강력한 차단이며, 데이터베이스 업데이트 폭발 위험이 있고, 외부 키는 데이터베이스 삽입 속도에 영향을 미치기 때문입니다. | 강제로 |
| | 저장 프로시저 | 저장 프로시저는 금지되어 있으며, 저장 프로시저는 디버깅과 확장이 어렵고 이식성이 없습니다. | 강제로 |
| | 데이터 정정 | 데이터를 수정할 때(특히 레코드 삭제 또는 수정 시), 우발적인 삭제를 방지하기 위해 먼저 선택하고, 업데이트 문이 올바른지 확인한 후에만 실행할 수 있습니다. | 강제로 |
| | 피할 수 없다면, 그 이후에 들어가는 집합 요소의 수는 1000개 이내로 통제해야 합니다. | 추천 |
| | 절단 테이블 | 트런케이트 테이블 사용은 금지되어 있는데, 이는 삭제보다 빠르고 시스템 및 로그 자원을 적게 사용하지만, 트런케이트는 트랜잭션이 없고 트리거를 트리거하지 않아 사고가 발생할 수 있으므로 개발 코드에서는 이 문장을 사용하지 마세요. | 참조 |
|
5. ORM 철의 법칙 지도
| - | 철의 법칙 | 레벨 | 말 | 테이블 쿼리 | 쿼리에 * 사용을 금지하는 필드 목록은 어떤 필드가 필요한지 명확히 해야 합니다. | 강제로 |
| | 포조 | POJO 클래스의 불리언 속성은 is에 추가할 수 없지만, 데이터베이스 필드는 is에 추가해야 하므로 resultMap에서 필드와 속성 간의 매핑이 필요합니다. | 강제로 |
| | 반환 매개변수 | resultClass 이름을 반환 매개변수로 사용하는 것은 금지되어 있으며, 모든 클래스 속성 이름이 데이터베이스 필드에 하나씩 대응하더라도 반드시 정의해야 합니다; 각 테이블은 반드시 해당 속성이 있어야 합니다. 이유: 필드와 DO 클래스를 결합하도록 매핑 관계를 설정해 유지보수를 용이하게 하세요. | 강제로 |
| | 반환 매개변수 | HashMap과 HashTable을 쿼리 결과 집합의 출력으로 직접 사용하는 것은 금지되어 있습니다. 이유: 속성 가치의 유형이 통제할 수 없기 때문입니다. | 강제로 |
| | sql.xml 매개변수 구성 | sql.xml 구성 매개변수로 #{}, #param#를 사용하고, ${}는 SQL 인젝션에 취약하므로 사용하지 마세요. | 강제로 |
| | queryForList | Mybatis에 포함된 queryForList(String statementName, int start, int size) 사용은 금지되어 있습니다. 이유: 데이터베이스에서 문장Name에 대응하는 SQL 문장의 모든 레코드를 가져와서, subList를 사용해 start, size의 부분집합을 얻는 방식으로 구현됩니다. | 강제로 |
| | 업데이트 시간 | 데이터베이스 테이블 레코드를 업데이트할 때는 레코드의 수정 시간도 동시에 업데이트해야 합니다. | 강제로 |
| | 데이터베이스 테이블 레코드 업데이트 | POJO 클래스로 전달되는 크고 완전한 데이터 업데이트 인터페이스를 작성하지 마세요. SQL 실행 시에는 오류가 발생하기 쉽고 비효율적이며 빈로그 저장 용량이 증가하기 때문에 변경되지 않은 필드는 업데이트하지 마십시오. | 추천 |
| | @Transactional | @Transactional 거래를 남용하지 마세요. 트랜잭션은 데이터베이스의 QPS에 영향을 미칩니다. 또한, 트랜잭션을 사용할 때는 캐시 롤백, 검색 엔진 롤백, 메시지 보상, 통계적 보정 등 롤백 방식의 다양한 측면을 고려해야 합니다. | 참조 |
| | Mybatis 동적 SQL 태그 | isEqual<에서 compareValue>는 속성 값에 대한 상수이며, 보통 숫자로, 해당 SQL 문이 같을 때 실행됨을 나타냅니다; < isNotEmpty>는 비어 있지 않고 null이 아닐 때 실행됨을 나타냅니다; isNotNull> <는 null이 아닐 때 실행됨을 나타냅니다. | 참조 | |
|
게시됨 2019. 10. 10. 오후 2:00:44
|
|
|
