[design-patterns] 관계형 데이터베이스 디자인 패턴? [닫은]

Program / 글쓴이

디자인 패턴은 일반적으로 객체 지향 디자인과 관련이 있습니다.
이 있습니까 디자인 패턴 생성 및 프로그래밍하기위한 관계형 데이터베이스는 ?
많은 문제에는 반드시 재사용 가능한 솔루션이 있어야합니다.

예에는 테이블 디자인, 스토어드 프로 시저, 트리거 등의 패턴이 포함됩니다.

martinfowler.com 과 유사한 패턴의 온라인 저장소가 있습니까?

패턴으로 해결할 수있는 문제의 예 :

  • 계층 적 데이터 저장 (예 : 유형이있는 단일 테이블과 1 : 1 키가있는 여러 테이블 및 차이점 …)
  • 가변 구조로 데이터 저장 (예 : 일반 열 대 XML 대 구분 열 …)
  • 데이터의 비정규 화 (영향을 최소화하면서 수행하는 방법 등)

답변

Martin Fowler의 Signature Series에는 Refactoring Databases 라는 책이 있습니다 . 데이터베이스 리팩토링 기술 목록을 제공합니다. 데이터베이스 패턴 목록을 많이 들었다고 말할 수는 없습니다.

또한 David C. Hay의 데이터 모델 패턴 과 후속 메타 데이터 맵 을 강력히 추천합니다.이 맵 은 처음에 작성되었으며 훨씬 야심적이고 흥미로 웠습니다. 서문만으로도 깨달았습니다.

또한 사전 통조림 데이터베이스 모델을 찾기에 좋은 곳은 Len Silverston의 데이터 모델 리소스 북 시리즈 1 에 보편적으로 적용 가능한 데이터 모델 (직원, 계정, 배송, 구매 등)이 포함되어 있고, 2 권 에는 산업별 데이터 모델 (회계, 헬스 케어 등), Volume 3 은 데이터 모델 패턴을 제공합니다.

마지막으로이 책은 UML과 Object Modelling에 대해 다루고 있지만 Peter Coad의 UML을 사용한 모델링은 개체 / 데이터 모델의 4 가지 핵심 아키 타입이 있다는 전제에서 시작하여 “아키 타입”중심의 엔티티 모델링 프로세스를 제공합니다.

답변

디자인 패턴은 사소하게 재사용 가능한 솔루션이 아닙니다.

디자인 패턴은 정의에 따라 재사용 할 수 있습니다. 그들은있는 거 패턴 당신은 다른 좋은 솔루션을 감지합니다.

패턴은 사소하게 재사용 할 수 없습니다. 그러나 패턴에 따라 다운 디자인을 구현할 수 있습니다.

관계형 디자인 패턴에는 다음이 포함됩니다.

  1. 외래 키를 사용한 일대 다 관계 (마스터-상세, 부모-자식) 관계

  2. 브릿지 테이블과의 다 대다 관계.

  3. 선택적인 일대일 관계는 FK 열에서 NULL로 관리됩니다.

  4. 스타 스키마 : 차원 및 사실, OLAP 디자인.

  5. 완전히 정규화 된 OLTP 디자인.

  6. 차원의 여러 색인화 된 검색 열

  7. 하나 이상의 응용 프로그램에서 사용하는 PK, 설명 및 코드 값이 포함 된 “조회 테이블” 왜 코드가 있습니까? 모르겠지만 코드를 사용해야 할 때 코드를 관리 할 수 ​​있습니다.

  8. 유니 테이블. [어떤 사람들은 이것을 반 패턴이라고 부릅니다. 패턴이고 때로는 나쁘고 때로는 좋은 경우도 있습니다.] 이것은 두 번째 및 세 번째 정규 형식을 위반하는 미리 결합 된 많은 항목이있는 테이블입니다.

  9. 배열 테이블. 이 열은 열에 배열이나 값 시퀀스를 가짐으로써 첫 번째 정규 형식을 위반하는 테이블입니다.

  10. 혼합 사용 데이터베이스. 데이터베이스는 트랜잭션 처리를 위해 표준화되었지만보고 및 분석을위한 추가 인덱스가 많이 있습니다. 반 패턴입니다. 이러지 마십시오. 어쨌든 사람들은 그렇게하기 때문에 여전히 패턴입니다.

데이터베이스를 디자인하는 대부분의 사람들은 쉽게 다스 “여러 가지 중 하나”를 약탈 할 수 있습니다. 이들은 정기적으로 사용하는 디자인 패턴입니다.

여기에는 관리 및 운영 패턴의 사용 및 관리가 포함되지 않습니다.

답변

AskTom 은 Oracle DB의 모범 사례에 대한 가장 유용한 단일 리소스 일 것입니다. (보통 특정 주제에 대한 Google 검색어의 첫 단어로 “asktom”을 입력합니다)

관계형 데이터베이스로 디자인 패턴을 말하는 것이 실제로 적절하지 않다고 생각합니다. 관계형 데이터베이스는 이미 문제에 “디자인 패턴”을 적용하고 있습니다 (문제는 “무결성을 유지하면서 데이터를 표현, 저장 및 사용하는 방법”및 디자인이 관계형 모델 임). 다른 접근 방식 (일반적으로 사용되지 않는 것으로 간주 됨)은 탐색 및 계층 적 모델입니다 (그리고 다른 많은 것들도 존재합니다).

그러나 “데이터웨어 하우징”은 데이터베이스 디자인에서 다소 분리 된 “패턴”또는 접근 방식으로 간주 할 수 있습니다. 특히 Star 스키마 에 대해 읽고 싶을 것 입니다.

답변

몇 년 동안 데이터베이스를 개발 한 후에는 시작하기 전에 대답 할 질문이 없다고 말할 수 있습니다.

질문 :

  • 향후 다른 DBMS를 사용 하시겠습니까? 그렇다면 현재 DBMS의 특수 SQL 항목에 사용하지 않습니다. 응용 프로그램에서 논리를 제거하십시오.

사용하지 않습니다 :

  • 테이블 이름 및 열 이름의 공백
  • 테이블 및 열 이름의 비 ASCII 문자
  • 특정 소문자 또는 대문자에 바인딩합니다. 소문자와 대문자 만 다른 2 개의 테이블 또는 열을 사용하지 마십시오.
  • “FROM”, “BETWEEN”, “DELETE”등과 같은 테이블 또는 열 이름에는 SQL 키워드를 사용하지 않습니다.

추천 :

  • 유니 코드 지원에 NVARCHAR 또는 이와 동등한 기능을 사용하면 코드 페이지에 문제가 없습니다.
  • 모든 열에 고유 한 이름을 지정하십시오. 따라서 조인시 열을 쉽게 선택할 수 있습니다. 모든 테이블에 열 “ID”또는 “이름”또는 “설명”이 있으면 매우 어렵습니다. XyzID 및 AbcID를 사용하십시오.
  • 복잡한 SQL 표현식에는 자원 번들을 사용하십시오. 다른 DBMS로 쉽게 전환 할 수 있습니다.
  • 어떤 데이터 유형에도 열심히 캐스트하지 않습니다. 다른 DBMS는이 데이터 유형을 가질 수 없습니다. 예를 들어 Oracle은 숫자 만 SMALLINT가 없습니다.

이것이 좋은 출발점이되기를 바랍니다.

답변

귀하의 질문은 약간 모호하지만 UPSERT디자인 패턴으로 간주 될 수 있다고 생각합니다. 구현하지 않는 언어의 경우 MERGE, 문제를 해결하기위한 대안의 수 (적절한 행이 존재하는 경우를, UPDATE그렇지 않은 INSERT) 존재한다.

답변

패턴의 의미에 따라 다릅니다. Person / Company / Transaction / Product 등을 생각하고 있다면 예-이미 사용할 수있는 많은 일반 데이터베이스 스키마가 있습니다.

Factory, Singleton을 생각하고 있다면 … 아니요-DB 프로그래밍에 비해 너무 낮은 수준이기 때문에 필요하지 않습니다.

데이터베이스 객체 이름을 생각하고 있다면 디자인 자체가 아닌 규칙 범주에 속합니다.

BTW, S.Lott, 일대 다 및 다 대다 관계는 “패턴”이 아닙니다. 그것들은 관계형 모델의 기본 구성 요소입니다.

답변