데이터베이스 설계의 잘못된 관행: 이러한 실수를 하고 있습니까?

개발자로서 기존 코드를 기반으로 하는 작업이 주어질 때마다 많은 문제에 직면해야 합니다. 그러한 과제 중 하나는 가장 까다로운 것이 아니라 응용 프로그램의 데이터 모델을 이해하는 것과 관련이 있습니다.

일반적으로 이해하는 데 시간이 오래 걸리는 혼란스러운 테이블, 보기, 열, 값, 저장 프로시저, 함수, 제약 조건 및 트리거에 직면하게 됩니다. 그리고 일단 그렇게 하면 저장된 정보를 개선하고 활용할 수 있는 여러 가지 방법을 알아차리기 시작합니다.

경험 많은 개발자라면 처음에 더 잘할 수 있었던 것, 즉 디자인 결함을 발견할 가능성이 있습니다.

이 기사에서는 몇 가지 일반적인 데이터베이스 설계의 잘못된 관행, 그것이 나쁜 이유, 그리고 이를 방지할 수 있는 방법에 대해 배울 것입니다.

나쁜 습관 1: 데이터의 목적 무시

데이터는 나중에 사용하기 위해 저장되며 목표는 항상 가장 효율적인 방식으로 저장하고 검색하는 것입니다. 이를 달성하기 위해 데이터베이스 설계자는 데이터가 무엇을 나타낼 것인지, 어떻게 획득할 것인지, 어느 정도의 비율로 획득할 것인지, 운영 볼륨이 얼마인지(즉, 예상되는 데이터의 양), 마지막으로 , 사용 방법.

예를 들어, 매일 수동으로 데이터를 수집하는 산업 정보 시스템은 정보가 실시간으로 생성되는 산업 시스템과 동일한 데이터 모델을 갖지 않습니다. 왜요? 같은 기간에 수백만 개의 레코드를 관리하는 것과 한 달에 수백 또는 수천 개의 레코드를 처리하는 것은 매우 다르기 때문입니다. 데이터 볼륨이 클 경우 데이터베이스의 효율성과 사용성을 유지하기 위해 설계자는 특별한 고려를 해야 합니다.

그러나 물론 데이터의 목적이 정규화 수준, 데이터 구조, 레코드 크기 및 전체 시스템의 일반적인 구현에 영향을 미치기 때문에 데이터 볼륨이 고려해야 할 유일한 측면은 아닙니다.

따라서 생성할 데이터 시스템의 목적을 철저히 알고 있으면 데이터베이스 엔진, 디자인할 엔터티, 레코드 크기 및 형식, 데이터베이스 엔진 관리 정책을 선택할 때 고려해야 합니다.

이러한 목표를 무시하면 구조적으로나 수학적으로는 정확하지만 기본에 결함이 있는 설계로 이어집니다.

나쁜 습관 2: 정규화 불량

데이터베이스를 설계하는 것은 결정적인 작업이 아닙니다. 두 명의 데이터베이스 디자이너가 주어진 문제에 대한 모든 규칙과 정규화 원칙을 따를 수 있으며 대부분의 경우 서로 다른 데이터 레이아웃을 생성합니다. 이것은 소프트웨어 엔지니어링의 창조적인 특성에 내재되어 있습니다. 그러나 모든 경우에 의미가 있는 몇 가지 분석 기술이 있으며 이를 따르는 것이 최상의 성능을 내는 데이터베이스에 도달하는 가장 좋은 방법입니다.

그럼에도 불구하고 우리는 가장 기본적인 정규화 규칙을 따르지 않고 즉석에서 설계된 데이터베이스에 자주 직면합니다. 우리는 다음을 분명히 해야 합니다. 모든 데이터베이스는 최소한 3차 정규화 형식으로 정규화되어야 합니다. 이는 엔터티를 가장 잘 나타내는 레이아웃이고 쿼리 및 삽입-업데이트-삭제 레코드 간의 성능 균형이 가장 잘 맞을 것이기 때문입니다. .

3NF, 2NF 또는 1NF를 준수하지 않는 테이블을 발견했다면 이 테이블을 다시 디자인하는 것을 고려하십시오. 그렇게 하는 데 투자한 노력은 매우 단기간에 결실을 맺을 것입니다.

나쁜 습관 3: 중복성

이전 요점과 매우 관련이 있습니다. 정규화의 목표 중 하나가 이를 줄이는 것이기 때문에 중복은 꽤 자주 나타나는 또 다른 나쁜 습관입니다.

중복 필드와 테이블은 동일한 정보의 여러 버전을 최신 상태로 유지하기 위해 비즈니스 로직이 필요하기 때문에 개발자에게 악몽입니다. 이것은 정규화 규칙을 철저히 따를 경우 피할 수 있는 오버헤드입니다. 때로는 중복이 필요한 것처럼 보일 수 있지만 매우 특정한 경우에만 사용해야 하며 향후 개발에서 고려할 수 있도록 명확하게 문서화해야 합니다.

이중화의 일반적인 나쁜 영향은 데이터베이스 크기가 불필요하게 증가하고 데이터가 일관성을 유지하지 못하고 데이터베이스 효율성이 감소하는 것입니다. 그러나 더 중요한 것은 데이터 손상으로 이어질 수 있다는 것입니다.

나쁜 관행 4: 잘못된 참조 무결성(제약 조건)

참조 무결성은 데이터 품질을 최상의 상태로 유지하기 위해 데이터베이스 엔진이 제공하는 가장 가치 있는 도구 중 하나입니다. 설계 단계에서 제약 조건이 구현되지 않거나 매우 적은 제약 조건이 구현된 경우 데이터 무결성은 비즈니스 논리에 전적으로 의존해야 하므로 인적 오류에 취약합니다.

나쁜 습관 5: DB 엔진 기능을 활용하지 않는 것

데이터베이스 엔진(DBE)을 사용하는 경우 소프트웨어 개발을 단순화하고 정보가 항상 정확하고 안전하며 사용 가능하도록 보장하는 데이터 처리 작업을 위한 강력한 소프트웨어가 있습니다. DBE는 다음과 같은 서비스를 제공합니다.

• 데이터를 보는 빠르고 효율적인 방법을 제공하는 보기로, 일반적으로 데이터 정확성을 잃지 않고 쿼리 목적으로 데이터를 비정규화합니다.
• 테이블에 대한 쿼리 속도를 높이는 데 도움이 되는 인덱스입니다.
• 프로그래밍 없이 정보를 분석하는 데 도움이 되는 집계 기능.
• 예상치 못한 일이 발생하면 모두 실행되고 커밋되거나 취소(롤백)되어 정보를 영구적으로 올바른 상태로 유지하는 트랜잭션 또는 데이터 변경 문장 블록입니다.
• 트랜잭션이 실행되는 동안 데이터를 안전하고 올바르게 유지하는 잠금입니다.
• 복잡한 데이터 관리 작업을 허용하는 프로그래밍 기능을 제공하는 저장 프로시저입니다.
• 정교한 계산과 데이터 변환을 가능하게 하는 함수.
• 데이터 정확성을 보장하고 오류를 방지하는 데 도움이 되는 제약 조건입니다.
• 데이터에서 이벤트가 발생할 때 작업을 자동화하는 데 도움이 되는 트리거입니다.
• 후드 아래에서 실행되는 명령 최적화 프로그램(실행 플래너)으로 모든 문장이 최상의 상태로 실행되고 미래의 경우를 위한 실행 계획이 유지됩니다. 뷰, 저장 프로시저 및 함수의 실행 계획이 DBE에 영구적으로 유지되기 때문에 이것이 뷰, 저장 프로시저 및 함수를 사용하는 가장 좋은 이유 중 하나입니다.

이러한 기능을 알지 못하거나 무시하면 개발이 극도로 불확실한 경로로 진행되고 확실히 버그와 미래 문제가 발생합니다.

나쁜 습관 6: 복합 기본 키

이것은 오늘날 많은 데이터베이스 설계자가 두 개 이상의 필드 조합으로 정의된 복합 필드 대신 기본 키로 정수 ID 자동 생성 필드를 사용하는 것에 대해 이야기하기 때문에 논란의 여지가 있는 부분입니다. 이것은 현재 "모범 사례"로 정의되며 개인적으로 동의하는 경향이 있습니다.

그러나 이것은 단지 관례일 뿐이며, 물론 DBE는 많은 설계자가 피할 수 없다고 생각하는 복합 기본 키의 정의를 허용합니다. 따라서 중복성과 마찬가지로 복합 기본 키는 설계 결정입니다.

그러나 복합 기본 키가 있는 테이블에 수백만 개의 행이 있을 것으로 예상되는 경우 복합 키를 제어하는 ​​인덱스가 CRUD 작업 성능이 매우 저하되는 지점까지 커질 수 있습니다. 이 경우 인덱스가 충분히 압축되고 고유성을 유지하는 데 필요한 DBE 제약 조건을 설정하는 간단한 정수 ID 기본 키를 사용하는 것이 훨씬 좋습니다.

나쁜 습관 7: 잘못된 인덱싱

경우에 따라 여러 열로 쿼리해야 하는 테이블이 있습니다. 테이블이 커짐에 따라 이러한 열의 SELECT 속도가 느려지는 것을 알 수 있습니다. 테이블이 충분히 크면 논리적으로 이 테이블에 액세스하는 데 사용하는 각 열에 인덱스를 생성하여 SELECT의 성능은 향상되지만 INSERT, UPDATE 및 DELETE는 떨어지는 것을 거의 즉시 찾을 수 있다고 생각할 것입니다. 물론 이는 인덱스를 테이블과 동기화된 상태로 유지해야 하기 때문에 발생하며, 이는 DBE에 막대한 오버헤드를 의미합니다. 이것은 여러 가지 방법으로 해결할 수 있는 과도 인덱싱의 일반적인 경우입니다. 예를 들어, 테이블을 쿼리하는 데 사용하는 기본 키와 다른 모든 열에 하나의 인덱스만 있는 경우 이러한 열을 가장 많이 사용되는 것부터 가장 적게 사용하는 것 순으로 정렬하면 열당 하나의 인덱스보다 모든 CRUD 작업에서 더 나은 성능을 제공할 수 있습니다.

반면에 쿼리에 사용되는 열에 인덱스가 없는 테이블이 있으면 우리 모두 알다시피 SELECT에서 성능이 저하됩니다.

또한 인덱스 효율성은 때때로 열 유형에 따라 다릅니다. INT 열의 인덱스는 가능한 최고의 성능을 보여주지만 VARCHAR, DATE 또는 DECIMAL(적절한 경우)의 인덱스는 효율적이지 않습니다. 이러한 고려 사항은 최상의 효율성으로 액세스해야 하는 테이블을 재설계하는 것으로까지 이어질 수 있습니다.

따라서 인덱싱은 너무 많은 인덱싱이 너무 적은 만큼 나쁠 수 있고 인덱싱할 열의 데이터 유형이 최종 결과에 큰 영향을 미치기 때문에 항상 섬세한 결정입니다.

나쁜 습관 8: 잘못된 명명 규칙

이것은 프로그래머가 기존 데이터베이스에 직면할 때 항상 고심하는 것입니다. 테이블과 열의 이름으로 어떤 정보가 저장되어 있는지 이해하는 것입니다. 종종 다른 방법이 없기 때문입니다.

테이블 이름은 테이블이 보유한 엔터티를 설명해야 하고 각 열 이름은 테이블이 나타내는 정보를 설명해야 합니다. 이것은 쉽지만 테이블이 서로 관련되어야 하는 경우 복잡해지기 시작합니다. 이름이 지저분해지기 시작하고 더 나쁜 것은 이름 지정 규칙이 비논리적일 경우 혼란스러워집니다(예: "열 이름은 8자 이하여야 합니다"). 최종 결과는 데이터베이스를 읽을 수 없게 된다는 것입니다.

따라서 데이터베이스가 지원하는 응용 프로그램과 함께 지속되고 발전할 것으로 예상되는 경우 명명 규칙이 항상 필요합니다. 다음은 간결하고 간단하며 읽기 쉬운 데이터베이스를 설정하기 위한 몇 가지 지침입니다.

• 테이블 또는 열 이름 크기에 제한이 없습니다. 아무도 기억하거나 이해하지 못하는 두문자어보다 설명이 포함된 이름을 사용하는 것이 좋습니다.
• 동일한 이름은 동일한 의미를 갖습니다. 이름은 같지만 유형이나 의미가 다른 필드를 사용하지 마십시오. 이것은 조만간 혼란스러울 것입니다.
• 필요한 경우가 아니면 중복하지 마십시오. 예를 들어 "Item" 테이블에는 "ItemName", "PriceOfItem" 또는 유사한 이름과 같은 열이 필요하지 않습니다. "이름"과 "가격"이면 충분합니다.
• DBE 예약어에 주의하십시오. 컬럼을 SQL 예약어인 “Index”라고 하는 경우 “IndexNumber”와 같이 다른 것을 사용해 보십시오.
• 간단한 기본 키 규칙(단일 정수 자동 생성)을 고수하는 경우 모든 테이블에서 이름을 "Id"로 지정합니다.
• 다른 테이블에 조인하는 경우 필요한 외래 키를 "Id"라는 이름 뒤에 조인된 테이블의 이름(예: IdItem)이 오는 정수로 정의합니다.
• 이름 지정 제약 조건인 경우 제약 조건을 설명하는 접두사(예: "PK" 또는 "FK")를 사용하고 그 뒤에 관련된 테이블 이름을 사용합니다. 물론 밑줄("_")을 조금만 사용하면 내용을 더 쉽게 읽을 수 있습니다.
• 인덱스의 이름을 지정하려면 접두사 "IDX" 다음에 테이블 이름과 인덱스의 열 또는 열을 사용합니다. 또한 인덱스가 고유한 경우 접두사 또는 접미사로 "UNIQUE"를 사용하고 필요한 경우 밑줄을 사용합니다.

인터넷에는 데이터베이스 디자인의 이 매우 중요한 측면에 대해 더 많은 정보를 제공하는 데이터베이스 명명 지침이 많이 있지만 이러한 기본 지침을 사용하면 최소한 읽을 수 있는 데이터베이스에 도달할 수 있습니다. 여기서 중요한 것은 명명 지침의 크기나 복잡성이 아니라 준수하는 일관성입니다!

몇 가지 최종 발언

데이터베이스 디자인은 지식과 경험의 조합입니다. 소프트웨어 산업은 초창기부터 많은 발전을 이루었습니다. 다행히 데이터베이스 설계자가 최상의 결과를 얻는 데 도움이 되는 지식이 충분합니다.

인터넷에는 좋은 데이터베이스 설계 지침뿐만 아니라 데이터베이스 설계에서 피해야 할 나쁜 관행과 사항이 있습니다. 그냥 선택하고 그것에 충실합니다.

그리고 잊지 마세요. 오직 실험, 실수, 성공을 통해서만 배울 수 있으므로 지금 바로 시작하십시오.