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

283

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

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

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

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

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

design-patterns database-design rdbms

— 개정
소스

계층 적 데이터 스토리지에 대한 최고의 Q & A를 주장하겠습니다 : stackoverflow.com/questions/4048151/…

— orangepips

1

Google 의 주제별 안내 에 따르면 , " 일부 질문은 위에 나열된 카테고리 중 하나에 해당하더라도 여전히 주제가 맞지 않습니다. ... 책, 도구, 소프트웨어 라이브러리, 튜토리얼 또는 기타 를 추천하거나 찾 도록 요청하는 질문 외부 자원 이 주제에

— Robert Columbia

@RobertColumbia 질문은 2008 년에 주제 에 관한 것이 었 습니다 .

— Sklivvz

관계형 데이터베이스와 소프트웨어 엔지니어링의 많은 영역에서이 디자인 패턴 리소스 목록을 확인하십시오. github.com/DovAmir/awesome-design-patterns

— dov.amir

150

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

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

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

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

— 마이클 브라운
소스

1

이 책의 제목은 Scott W. Ambler와 Pramod J. Sadalage의 [리팩토링 데이터베이스 : 진화 데이터베이스 디자인] [1]이며 실제로 매우 좋습니다. [1] : ambysoft.com/books/refactoringDatabases.html

— Panos

3

Ambler 서적 관련 : 아니오, 같은 이유로 "열 삽입"또는 "FK 제한 조건 작성"을 패턴으로 나열 할 수 없습니다. Gang of 4 서적은 "for"루프를 패턴으로 나열하지 않습니다.

— Tegiri Nenashi

리팩토링 패턴이 아닙니다. 추출 방법과 같거나 매개 변수 이름을 바꿉니다. 리팩토링과 패턴은 서로 밀접한 관련이 있습니다.

— Michael Brown

하나 추가 : Fowler의 "분석 패턴". Hay의 물건과 유사

— Neil McGuigan

2

Len Silverston의 3 권은 "디자인 패턴"으로 생각할 수있는 유일한 것입니다. 처음 2 개는 책이 작성된 시간 프레임에서 공통적 인 샘플 데이터 모델을 보여줍니다. 볼륨 3은 실제로 주어진 문제 시나리오에 대해 여러 디자인 패턴을 가지고 있습니다. 예를 들어, 4 장에서는 계층 / 집계 / 피어 투 피어 시나리오를 다루고 각각의 장단점을 다루는 여러 가지 디자인을 제공합니다.

— DarrellNorton

46

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

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

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

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

외래 키를 사용한 일대 다 관계 (마스터-상세, 부모-자식) 관계
브릿지 테이블과의 다 대다 관계.
선택적인 일대일 관계는 FK 열에서 NULL로 관리됩니다.
스타 스키마 : 차원 및 사실, OLAP 디자인.
완전히 정규화 된 OLTP 디자인.
차원의 여러 색인화 된 검색 열
하나 이상의 응용 프로그램에서 사용하는 PK, 설명 및 코드 값이 포함 된 "조회 테이블" 왜 코드가 있습니까? 모르겠지만 코드를 사용해야 할 때 코드를 관리 할 수 있습니다.
유니 테이블. [어떤 사람들은 이것을 반 패턴이라고 부릅니다. 패턴이고 때로는 나쁘고 때로는 좋은 경우도 있습니다.] 이것은 두 번째 및 세 번째 정규 형식을 위반하는 미리 결합 된 많은 항목이있는 테이블입니다.
배열 테이블. 이 열은 열에 배열이나 값 시퀀스를 가짐으로써 첫 번째 정규 형식을 위반하는 테이블입니다.
혼합 사용 데이터베이스. 데이터베이스는 트랜잭션 처리를 위해 표준화되었지만보고 및 분석을위한 추가 인덱스가 많이 있습니다. 반 패턴입니다. 이러지 마십시오. 어쨌든 사람들은 그렇게하기 때문에 여전히 패턴입니다.

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

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

— 로트
소스

내가 본 다른 패턴은 다중 부모 자식 테이블 (예 : 다른 테이블에 연결할 수있는 objecttype 및 objectid가있는 전역 노트) 또는 자체 참조 FK (예 : employee.manager-> employee)입니다. 신분증). 또한 많은 열이있는 단일 구성 테이블을 사용했습니다.

— r00fus

1

왜 혼합 사용 데이터베이스가 안티 패턴인가? 데이터베이스에서 보고서를 가져 오려면 어떻게해야합니까?

— 올리브

3

@lhnz : 당신은 풀 수없는 많은 의 큰 트랜잭션 데이터베이스 설계에서 보고서 - 거래를 느려지보고를 위해 잠금. 복잡한 조인 (반복 반복)은 트랜잭션 성능에 대한 또 다른 노크입니다. 하나의 데이터베이스에서 두 가지를 모두 수행 할 수는 없습니다. 많은 양의 보고서를 작성하려면 데이터를 스타 스키마로 이동해야합니다. 스타 스키마 패턴은보고에 최적화되어 있습니다. 데이터를 이동하면 잠금 경합이 제거됩니다.

— S.Lott

테이블을보다 "일관성있는"데이터를 보유하게하면 스키마를 정규화하면 행 잠금 경합이 줄어 듭니까? 내 생각은 큰 테이블이 2 종류의 데이터 세트에 대한 쓰기를 처리하지만 둘 다 동일한 행에 있으면 불필요한 잠금 경합이 발생한다는 것입니다.

— CMCDragonkai

6

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

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

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

— 갈가 몬
소스

4

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

질문 :

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

사용하지 않습니다 :

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

추천 :

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

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

— Horcrux7
소스

7

귀하의 의견은 매우 유익하고 유용하지만 디자인 패턴이 아닙니다. 모범 사례입니다. 감사합니다,

— Sklivvz

7

고유 한 열 이름에 대한 권장 사항에 동의하지 않습니다. 명확하지 않은 부분이 있더라도 customerid를 말하는 것보다 customer.id를 명확하게 말하고 싶습니다.

— Paul Tomblin

1

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

— 소렌 쿠 클라우
소스

UPSERT는 명령이며 SQL 언어의 일부입니다. 패턴이 아닙니다.

— Todd R

UPSERT는 SQL 언어의 일부 변형에서 사용되는 명령입니다. 여러 플랫폼에없는 명령이 있거나 최근에만 사용되었습니다.

— Steve Homer

@ToddR-나는 (약간 냉소적으로) "패턴"은 언어 나 모델의 단점 일 뿐이며 사용자가 해결 방법을 만들어야한다는 말을 들었다. UPSERT의 기능을 모르지만 일부 SQL 에는 추가되었지만 다른 SQLUT 에는 추가 되지 않은 패턴입니다.

— Martin F

1

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

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

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

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

— 앤드류는 성자가 아니라
소스

(사람, 고객, 직원)과 같은 데이터베이스 상속은 어떤 종류의 디자인 패턴으로 간주 될 수 있습니까?

— Muflix