데이터베이스 설계 모범 사례
저는 SQL Server, MySQL, Oracle이 정통하지만 데이터베이스 제품을 제쳐두고 관계형 데이터베이스를 잘 설계하는 데 도움이되는 리소스가? 데이터베이스 디자인에 대한 모범 사례와 같은 체계적인 패턴이나?
나는 데이터베이스가 종종 확장 가능하지 않다는 것을 몇 번 내장합니다. 사람들은 기본으로 부울이지만 0과 1 대신 'Y'와 'N'과 같은 값을 가진 Char (1)로 저장되는 isChecked 열과 같은 열을 유지하는 개인 취향을 가지고 있습니다. 데이터베이스 디자인을하는 동안 일반적인 실수를 저 지르지 않는 방법은 무엇입니까?
책이나 기사에 대한 링크는 높이 평가 될 것입니다.
미리 감사드립니다.
몇 가지 사항 :
- 문제 도메인 에 대해 최대한 많이 배우십시오 . 무엇을 설계하고 있는지 모르면 좋은 데이터 모델을 만들 수 없습니다.
- 데이터베이스 공급자가 제공하는 데이터 유형 에 대해 잘 알고 있어야 합니다.
- 정규화 및 디자인 테이블 을 사용하는 방법
- 성능 : 인덱스 적용시기 및 방법 , 효율적인 쿼리 작성 방법 등
- 뷰, 프로 시저, 함수, 트리거와 같은 다양한 DB 개체를 사용하는시기와 방법
수많은 데이터베이스 디자인 패턴이 있습니다. 형식화되지 않은 경우가 많고 많은 데이터베이스 디자인을 볼 수 있습니다.
예를 들어, 디자인 패턴에 관한 Fowler의 책 을 참조하십시오 . 또한 Nock의 책 .
데이터베이스 프로그래머 와 같은 블로그가 있습니다 .
IEEE 책, On Pattern-Based Database Design and Implementation이 있습니다.
Google 검색 ( 링크 )은 2,400 만 건의 글을 기록했습니다.
이것에 대한 나의 견해는 다소 반대입니다. 나는 데이터베이스의 디자인을 너무 강조하지 말라고 조언 할 것이다.
여기에서 어려운 것이 있습니다. 내부 LOB 응용 프로그램에서 비즈니스에 대한 관점은 데이터가 기본 자산 인 경우가 많으며 소프트웨어는 다소 소모적입니다.
내 충고는 : 그것을 사지 기기.
실제로 자산은 데이터와 상호 작용할 수있는 회사의 능력입니다. 그것을보고, 그것을 조작하고, 그것을 기반으로 결정을 내리는 것입니다.
이 데이터에 높은 가치를 부여 할 수 있습니다. 가치있는 것은 당신이 작성하는 소프트웨어라는 것을 의미합니다.
즉, "완벽한 데이터베이스 설계"보다는 효과적인 사용자 경험을 구축하는 데 대부분의 노력을 집중할 것입니다. 데이터베이스는 실제로 사용자 환경을 제공 할 수있는 도구 일뿐입니다.
관계형 데이터 모델의 핵심 기능은 데이터 및 액세스 경로 독립성입니다. 열을 추가하고, 키를 변경하고 색인을 도입하거나 제거하는 등의 작업을 수행하는 동시에 사용하는 애플리케이션에 영향을주지 않고 거의 0에 가깝게 할 수 있습니다.
이 데이터베이스 구조는 매우 유연하게 만듭니다.
"미래에 유연하게"또는 "성능 최적화"를 위해 데이터베이스를 설계하는 것이 대부분 가능합니다.
서버 데이터베이스 구조를 변경하면 시스템에 작은 영향을 미칩니다.
또한 확장이 필요한 시나리오에 도달 할 때까지 데이터베이스 확장 방법을 예측할 수 없습니다. 가장 좋은 방법은 성능 문제가 보관 될 때까지 보관 될 것입니다. 설명합니다.
그러나 앱의 사용자 경험을 변경하는 것은 일반적으로 더 많은 비용이 소요됩니다. UI 작업은 시간이 많이 걸리며 일반적으로 작동하는 데 시간이 걸립니다.
따라서 다음을 권장합니다.
- 엉뚱한 DB 디자인을 만들어
- 발생하는 실제 성능 시나리오에 대응
- 데이터베이스가 아닌 사용자 경험에 집중하십시오.
Dillie-O의 조언에 맞서기 위해. 조회를 하나 모든의 테이블에 넣지 않는 것이 좋습니다 . 일반적으로 이것은 OO 디자인을 관계형 데이터베이스로 강제하려는 시도입니다. 그것은 할 수 있고 OO 개발자의 세계관에 맞지만, 데이터베이스 설계를 무너 뜨립니다.
Google로 이동하여 "MUCK Tables"를 검색하면 Massively Unified Code-Key Tables에 대한 토론으로 이어집니다. 또는 토론을 위해 "하나의 실제 조회 테이블"을 사용할 수 있습니다. 또는 Joe Celko의 가이드 하나의 True Lookup Table을 읽어보십시오 .
이 질문에서 내가 준비하는 것을 찾지 못했지만 여기서 DB 디자인의 디자인 패턴에 대한 권장 사항이 많이 있습니다.
계산 된 값을 저장하지 않습니다.
예를 들어, "width"열이있는 "Squares"테이블이 있습니다. 너비 ^ 2를 통해 계산할 수 있으므로 열 "면적"을 만들 필요가 없습니다.
여느 때와 여기에 대한 대답은 "따르다"입니다.
배포는 다양한 작업을 수행하는 데 필요한 설계 및 개발에서 반대 방향이 필요합니다.
OLTP 데이터베이스 시스템은보고 또는웨어 솔루션으로 사용되는 시스템과 완전히 다르게 설계됩니다. 첫 번째는 종종 정규화되고 창고는 종종 비정규 화됩니다. 이렇게하면 시스템이 의도 한 동작에 대해 원하는 성능을 얻을 수 있습니다.
이 세그먼트 내에서 읽을 수 있습니다. 또는 쓰기가 많은지 여부에 따라 다른 설계 결정이 있습니다.
가장 좋은 방법은 구축하려는 애플리케이션 유형에 해당하는 훨씬 작은 데이터베이스 개발 세그먼트에 대한 모범 사례를 본 것입니다.
데이터베이스 디자인과 관련하여 내가 읽은 최고의 책은 Michael J Hernandez의 "Database Design for Mere Mortals"입니다. 이름은 모든 것이 용 책처럼 들리지만 수준의 사람들이 지식을 얻을 수 있습니다. 또한 사용되는 기술이 자체 데이터를보고 데이터를 구성하는 방법을 다루기 때문에 독립적입니다.
그는 또한 "SQL Queries for Mere Mortals"라는 쿼리 작성에 관한 책을 쓴데, 제가 들었던 (아직 읽지 않았다) 좋습니다.
관계형 데이터베이스는 매우 강력한 추상화입니다. 사실의 모음과 술어 미적분입니다. 뿐만 아니라 SQL은 행을 검사하기위한 하나의 절과 행 변경을위한 다른 절을 사용하여 명령 쿼리 분리를 적용합니다.
데이터베이스를 진실 추론 엔진으로 생각할 때 모델링하는 데이터에서 모순이 흐르지 않도록 설정하는 것이 좋습니다. 따라서 관계형 데이터베이스를 효과적으로 사용하려면 데이터베이스 디자인을 올바르게해야합니다. 객체 지향 프로그램의 설계와 달리 관계형 데이터베이스를 설계하는 방법에 대한 합의 된 견해가 있습니다. 데이터베이스 디자인에 대한 적절한 접근 방식은 가능한 한 정규화 하는 것입니다. 대부분의 사람들은 세 번째 정상 형태까지 정상화하지만 실제로는 다섯 번째 정상 형태까지 올라갈 수 있습니다.
가능한 경우 데이터베이스에서 null 열 값을 영구 삭제하려고합니다. 진실 추론 엔진으로서의 데이터베이스에 대한 나의 견해에 동의한다면, 널은 진짜 문제입니다. 데이터베이스에 null이 있으면 중간 제외 법칙이 적용 되지 않습니다 . 이것은 데이터베이스의 주어진 속성에 대한 "모순에 의한 증명"을 널이없는 것보다 더 어렵게 만듭니다. Null은 데이터베이스의 의미 체계를 불필요하게 복잡하게 만듭니다.
때때로 성능상의 이유로 정규화 규칙을 어길 필요가 있습니다. 그러나 특히 쿼리가 느린 것에 대한 데이터 를 확보하기 전에는이 작업을 수행하지 마십시오 . 종종 비정규 화보다는 신중하게 인덱스를 변경하여 쿼리 속도를 높일 수 있습니다.
마지막으로 직접 쿼리가 아닌 저장 프로 시저에 대한 단어입니다. 괜찮은 데이터베이스에서는 기본 테이블과 관계없이 저장 프로 시저에 대한 보안 권한을 설정할 수 있습니다. 이것은 그 자체로 저장 프로 시저를 광범위하게 사용하는 것을 고려할 충분한 이유입니다. 저장 프로 시저를 사용하면 직접 SQL 액세스로 가능한 것보다 더 엄격한 보안 모델을 구축 할 수 있습니다.
아마도 가장 유명한 모범 사례는 데이터베이스 정규화입니다. 이 기술 세트를 사용하면 중복 항목이 제거되고 필드가 논리적으로 그룹화되도록 데이터베이스를 설계 할 수 있습니다.
스키마의 설명 열에 열거 형을 문서화하지 않으면 '5'가 무엇인지 알아낼 수 있습니다.
Select name from peeps where accountStatusId = 5
그럼 이렇게
테이블을 사용하여 필드를 열거합니다. 예 :
Select name
from peeps p
join accountStatus s
on p.accountStatusID = s.asid
where s.accountStatus = 'ActiveDude'
Michael J. Hernandez Database Design for Mere Mortals 의 책 은 잘 작성되었으며 읽기 쉽습니다. 귀하의 모든 질문에 답해야합니다.
Hernandez는 또한 John L. Viescas와 함께 Mere Mortals 를 위한 SQL 쿼리를 공동 작성했습니다 .
책은 한 장에 약 60 달러입니다. 나는 나의 생명을 잃었 기 때문에 Queries for Mere Mortals의 CD를 찾으려고합니다. 누구든지 사본이 있으면 알려주십시오.
나는 데이터베이스가 정규화되고 VLDB를 만들고 있다면 올바르게 분할하면 괜찮을 것이라고 말할 것입니다. 다른 모범 사례에는 저장 프로 시저에 CRUD를 사용하고 모든 테이블이 올바르게 계단식으로 배열되도록하는 것이 포함됩니다. 다른 대부분은 주관적입니다. "Y / N"을 사용하는 것은 비트가 아직 도입되지 않았을 때의 구식 데이터베이스 프로그래밍입니다. "Y / N / Maybe"와 같은 확장 성 목적으로도 사용할 수 있지만 만약 그렇다면 인피 관행은이를 정규화하고 조회 테이블을 만들라고 말할 것입니다.
여기에서 꽤 좋은 것으로 입증 된 개념 중 하나는 "Lookup Code"테이블입니다. 효과적으로 코딩하거나 유형을 지정하는 항목에 대한 많은 참조가있는 데이터베이스가있는 경우 모든 항목을 CodeGroup 및 코드 자체를 기반으로하는 단일 LookupCode 테이블에 보관합니다.
코드의 활성 상태에 대한 추가 플래그와 지정된 조회 코드를 모든 종류의 방식으로 정렬하거나 계산해야하는 경우 사용할 수있는 몇 가지 선택적 숫자 열을 유지합니다.
이렇게하면 스키마 주변에 흩어져있는 아주 작은 테이블이 많이 없어집니다. 이제 이것의 단점 중 하나는 테이블의 기본 키가 코드 그룹과 코드 자체이므로 지정된 코드를 참조하는 "마스터"테이블에 연결된 외래 키가 없다는 것입니다. 응용 프로그램의 시행은이를 쉽게 수용 할 수 있습니다.
참고 URL : https://stackoverflow.com/questions/387339/database-design-best-practices
'ProgramingTip' 카테고리의 다른 글
| 힙 대신 스택을 사용하는 것이 가장 좋은 언제입니까? (0) | 2020.12.11 |
|---|---|
| Java에서 폴더를 스캔하는 방법은 무엇입니까? (0) | 2020.12.11 |
| SQL Server 2008에서 열 값을 어떻게 바꾸나요? (0) | 2020.12.11 |
| C # 사전에 대한 명명 규칙 (0) | 2020.12.11 |
| C #에서 날짜를 비교하는 방법 (0) | 2020.12.11 |