데이터베이스 설계에서 일반적인 실수

수백 개의 레코드 또는 수백만 개의 레코드를 보유하고있는 데이터베이스로 작업하는 경우에도 적절한 데이터베이스 디자인이 항상 중요합니다. 정보 검색이 훨씬 쉬워 질뿐만 아니라 장래에 데이터베이스를 쉽게 확장 할 수 있습니다. 불행히도 앞으로는 어려운 일이 될 수있는 몇 개의 함정에 빠지기 쉽습니다.

데이터베이스를 정규화하는 주제로 작성된 전체 서적이 있지만 이러한 일반적인 실수를 단순히 피하면 좋은 데이터베이스 설계를 제대로 수행 할 수 있습니다.

데이터베이스 실수 # 1 : 테이블의 필드 반복

좋은 데이터베이스 설계의 기본 원칙은 반복되는 데이터를 인식하고 반복되는 열을 자신의 테이블에 넣는 것입니다. 테이블의 필드를 반복하는 것은 스프레드 시트의 세계에서 온 사람들에게는 일반적이지만 스프레드 시트는 설계 상 편평한 경향이 있지만 데이터베이스는 관계형이어야합니다. 그것은 2D에서 3D로가는 것과 같습니다.

다행히도 반복되는 필드는 일반적으로 쉽게 발견 할 수 있습니다. 이 표를 살펴보십시오.

주문에 네 개의 제품이 포함되면 어떻게됩니까? 3 개 이상의 제품을 지원하려면 테이블에 다른 필드를 추가해야합니다. 또한 데이터 입력을 돕기 위해 테이블 ​​주위에 클라이언트 응용 프로그램을 구축 한 경우 새 제품 필드로 수정해야 할 수도 있습니다. 그리고 우리는 순서대로 젤리 빈들과 함께 모든 명령을 어떻게 찾을 수 있습니까? SELECT * FROM Products Product1 = 'Jelly Beans'OR Product2 = 'Jelly Beans'OR Product3 = 'Jelly Beans'. 다음과 같은 SQL 문으로 테이블의 모든 제품 필드를 쿼리해야합니다.

모든 정보를 함께 모으는 하나의 테이블을 갖는 대신에, 각각이 하나의 정보를 담고있는 세 개의 테이블을 가져야합니다. 이 예에서는 주문 자체, 모든 제품이 들어있는 Products 테이블 및 주문과 제품을 연결하는 ProductOrders 태블릿에 대한 정보가 포함 된 Orders 테이블이 필요합니다.

각 테이블에 고유 한 ID 필드가있는 방식에 유의하십시오. 이것이 기본 키입니다. 기본 키 값을 다른 테이블의 외래 키로 사용하여 테이블을 연결합니다. 기본 키와 외래 키에 대해 자세히 읽어보십시오.

Database Mistake # 2 : 테이블에 테이블 임베딩

이것은 또 다른 흔한 실수이지만 반복되는 필드만큼 항상 두드러지지는 않습니다. 데이터베이스를 설계 할 때 테이블의 모든 데이터가 자신과 관련되는지 확인해야합니다. 그것은 다른 점을 발견하는 것과 같은 아이의 게임과 같습니다. 바나나, 딸기, 복숭아 및 텔레비전 세트를 가지고 있다면 텔레비전 세트는 아마 다른 곳에있을 것입니다.

동일한 라인을 따라 영업 사원 테이블을 보유하고있는 경우 해당 테이블의 모든 정보는 해당 영업 사원과 구체적으로 관련되어야합니다. 해당 영업 사원에게 고유하지 않은 추가 정보는 데이터베이스의 다른 어딘가에 속할 수 있습니다.

이 테이블은 모두 개별 영업 사원과 관련이있는 것처럼 보일 수 있지만 테이블에 실제로 포함 된 테이블이 있습니다. Office와 OfficeNumber가 "Austin Downtown"으로 반복되는 방식에 유의하십시오. 사무실 전화 번호가 변경되면 어떻게됩니까? 변화하는 하나의 정보에 대해 전체 데이터 세트를 업데이트해야합니다. 이는 좋은 방법이 아닙니다. 이 필드는 자체 테이블로 이동해야합니다.

이 유형의 디자인은 영업 담당자 테이블에 혼란을 야기하지 않고도 Office 테이블에 추가 정보를 추가 할 수있는 기능을 제공합니다. 그 모든 정보가 영업 사원 테이블에 있다면 거리 주소, 도시, 주 및 우편 번호를 추적하는 것이 얼마나 많은 작업인지 상상해보십시오!

데이터베이스 실수 # 3 : 2 개 이상의 정보를 단일 필드에 넣기

영업 사원 테이블에 사무실 정보를 임베드하는 것이 그 데이터베이스의 유일한 문제는 아니 었습니다. 주소 필드에는 거리 주소, 도시 및 주 세 가지 정보가 포함되어 있습니다. 데이터베이스의 각 필드는 하나의 단일 정보만을 포함해야합니다. 단일 필드에 여러 개의 정보가있는 경우 정보를 데이터베이스에 쿼리하는 것이 어려워 질 수 있습니다.

예를 들어 오스틴의 모든 영업 사원에 대한 쿼리를 실행하려면 어떻게해야합니까? 우리는 주소 필드 내에서 검색 할 필요가 있습니다. 이는 비효율적 일뿐만 아니라 잘못된 정보를 반환 할 수 있습니다. 오레곤 포틀랜드의 오스틴 거리에 누군가가 살면 어떻게 될까요?

다음은 테이블의 모양입니다.

여기서 유의해야 할 몇 가지 사항이 있습니다. 첫째, "Address1"과 "Address2"는 반복되는 실수에 빠질 수 있습니다.

그러나이 경우에는 자체 테이블에 있어야하는 반복되는 데이터 그룹이 아닌 영업 담당자와 직접 관련이있는 별도의 데이터 조각을 나타냅니다.

또한 피해야 할 보너스 실수로 전화 번호 형식이 표에서 어떻게 제거되었는지 확인하십시오. 가능한 경우 필드의 형식을 저장하지 않아야합니다. 전화 번호의 경우 사람들이 전화 번호를 쓰는 방법에는 여러 가지가 있습니다. 215-555-5858 또는 (215) 555-5858. 이렇게하면 전화 번호로 영업 사원을 검색하거나 동일한 지역 번호의 영업 사원을 검색하는 것이 더 어려워집니다.

데이터베이스 실수 # 4 : 올바른 기본 키를 사용하지 않음

대부분의 경우 기본 키에 대해 자동으로 증가하는 숫자 나 다른 생성 된 숫자 또는 영숫자를 사용하려고합니다. 좋은 식별자를 만드는 것처럼 들리더라도 기본 키에 대한 실제 정보는 사용하지 않아야합니다.

예를 들어, 우리는 각각 자신의 개인 사회 보장 번호를 가지고 있기 때문에 직원 데이터베이스의 사회 보장 번호를 사용하는 것이 좋습니다. 드문 경우이지만 사회 보장 번호조차도 변경 될 수 있으며 기본 키가 변경되는 것을 결코 원하지 않습니다.

실제 정보를 핵심 가치로 사용하는 것이 문제입니다. 그것은 바뀔 수 있습니다.

데이터베이스 오류 # 5 : 명명 규칙을 사용하지 않음

처음에는 데이터베이스 설계를 시작할 때 큰 문제가 아니지만 정보를 검색하기 위해 데이터베이스에 대해 쿼리를 작성하면 명명 규칙을 사용하면 필드 이름을 기억할 때 도움이됩니다.

이름이 한 테이블의 이름, 성, 다른 테이블의 first_name, last_name으로 저장된 경우 프로세스가 얼마나 어려울 지 상상해보십시오.

두 가지 가장 유명한 명명 규칙은 필드의 모든 단어의 첫 글자를 대문자로 표시하거나 밑줄을 사용하여 단어를 분리하는 것입니다. 첫 번째 단어 인 firstName, lastName을 제외한 모든 단어의 첫 글자를 대문자로 표시하는 개발자도 있습니다.

단일 테이블 이름이나 복수 테이블 이름을 사용할지 여부를 결정할 수도 있습니다. 주문 표 또는 주문 표입니까? 고객 테이블 또는 고객 테이블입니까? 다시 말하지만, 당신은 Order 테이블과 Customers 테이블에 붙어 있기를 원하지 않습니다.

선택한 명명 규칙은 실제로 명명 규칙을 선택하고 사용하는 프로세스만큼 중요하지 않습니다.

데이터베이스 실수 # 6 : 부적절한 인덱싱

인덱싱은 특히 데이터베이스 디자인에 익숙한 사람들에게 가장 어려운 일 중 하나입니다. 모든 기본 키와 외래 키는 색인화되어야합니다. 이것들은 테이블을 함께 연결하는 것이므로 인덱스가 없으면 데이터베이스 성능이 매우 떨어집니다.

그러나 너무 자주 빠진 것은 다른 분야입니다. 이들은 "WHERE"필드입니다. WHERE 절의 필드를 사용하여 검색 범위를 좁히는 경우 해당 필드에 인덱스를 넣는 것에 대해 생각해보십시오. 그러나 테이블을 지나치게 색인화하지 않으려 고하므로 성능이 저하 될 수 있습니다.

결정하는 방법? 이것은 데이터베이스 디자인의 일부입니다. 테이블에 몇 개의 인덱스를 두어야하는지에 대한 엄격한 제한이 없습니다. 주로 WHERE 절에서 자주 사용되는 필드를 인덱싱하려고합니다. 데이터베이스 색인화에 대한 자세한 내용을 읽어보십시오.