진실 우선, 또는 시스템이 데이터베이스 구조를 기반으로 설계되어야 하는 이유

헤이 하브르!

우리는 주제를 계속 탐구합니다 자바 и 봄데이터베이스 수준을 포함합니다. 오늘 우리는 대규모 응용 프로그램을 설계할 때 Java 코드가 아니라 데이터베이스 구조가 결정적으로 중요한 이유, 이것이 수행되는 방법 및 이 규칙의 예외가 무엇인지에 대해 읽을 것을 제안합니다.

다소 뒤늦은 이 기사에서 나는 거의 모든 경우에 애플리케이션의 데이터 모델이 "Java의 기능"(또는 클라이언트 언어가 무엇이든)이 아니라 "데이터베이스에서" 설계되어야 한다고 생각하는 이유를 설명할 것입니다. 작업). 두 번째 접근 방식을 선택하면 프로젝트가 성장하기 시작하면 긴 고통과 괴로움의 길에 들어서게 됩니다.

바탕으로 작성한 글입니다 하나의 질문, 스택 오버플로에서 제공됩니다.

섹션의 reddit에 대한 흥미로운 토론 /r/자바 и /r/프로그래밍.

코드 생성

jOOQ를 알게 된 후 jOOQ가 소스 코드 생성에 심각하게 의존하여 실행된다는 사실에 분개하는 소수의 사용자 계층이 있다는 사실에 얼마나 놀랐습니까? 아무도 당신이 적절하다고 생각하는 방식으로 jOOQ를 사용하는 것을 막지 않으며, 아무도 당신이 코드 생성을 사용하도록 강요하지 않습니다. 그러나 기본적으로(매뉴얼에 설명된 대로) jOOQ는 다음과 같이 작동합니다. (레거시) 데이터베이스 스키마로 시작하여 jOOQ 코드 생성기로 리버스 엔지니어링하여 테이블을 나타내는 클래스 세트를 얻은 다음 유형을 작성합니다. 다음 테이블에 대한 안전한 쿼리:

	for (Record2<String, String> record : DSL.using(configuration)
//   ^^^^^^^^^^^^^^^^^^^^^^^ Информация о типах выведена на 
//   основании сгенерированного кода, на который ссылается приведенное
// ниже условие SELECT 
 
       .select(ACTOR.FIRST_NAME, ACTOR.LAST_NAME)
//           vvvvv ^^^^^^^^^^^^  ^^^^^^^^^^^^^^^ сгенерированные имена
       .from(ACTOR)
       .orderBy(1, 2)) {
    // ...
}

코드는 빌드 외부에서 수동으로 생성되거나 모든 빌드에서 수동으로 생성됩니다. 예를 들어, 이러한 재생은 직후에 뒤따를 수 있습니다. 수동 또는 자동으로 수행할 수도 있는 이동경로 데이터베이스 마이그레이션.

소스 코드 생성

코드 생성에 대한 이러한 접근 방식(수동 및 자동)과 관련된 다양한 철학, 장점 및 단점이 있으며 이 기사에서는 자세히 논의하지 않을 것입니다. 그러나 일반적으로 생성된 코드의 요점은 우리 시스템 내에서든 외부에서든 우리가 당연하게 여기는 "진실"을 Java로 재현할 수 있다는 것입니다. 어떤 의미에서 소스 코드에서 바이트 코드, 기계 코드 또는 다른 종류의 코드를 생성하는 컴파일러는 동일한 작업을 수행합니다. 특정 이유에 관계없이 다른 언어로 "진실"을 표현합니다.

그러한 코드 생성기가 많이 있습니다. 예를 들어, XJC는 XSD 또는 WSDL 파일을 기반으로 Java 코드를 생성할 수 있습니다.. 원칙은 항상 동일합니다.

• 일부 진실(내부 또는 외부)이 있습니다(예: 사양, 데이터 모델 등).
• 우리는 프로그래밍 언어로 이 사실을 지역적으로 표현할 필요가 있습니다.

또한 중복을 피하기 위해 이러한 표현을 생성하는 것이 거의 항상 권장됩니다.

유형 공급자 및 주석 처리

참고: jOOQ의 코드 생성에 대한 또 다른 보다 현대적이고 구체적인 접근 방식에는 유형 공급자 사용이 포함됩니다. F#에서 구현되므로. 이 경우 코드는 실제로 컴파일 단계에서 컴파일러에 의해 생성됩니다. 원칙적으로 이러한 코드는 소스 코드 형태로 존재하지 않습니다. Java에는 우아하지는 않지만 유사한 도구가 있습니다. 예를 들어 다음과 같은 주석 프로세서입니다. 칠레 고추를 넣은 저민 고기와 강낭콩 스튜.

어떤 의미에서, 다음을 제외하고는 첫 번째 경우와 동일한 일이 여기서 발생합니다.

• 생성된 코드가 보이지 않습니다.
• 유형을 제공할 수 있는지 확인해야 합니다. 즉, "true"를 항상 사용할 수 있어야 합니다. 이것은 "진실"로 주석이 달린 롬복의 경우에는 쉽습니다. 항상 사용 가능한 라이브 연결에 의존하는 데이터베이스 모델에서는 조금 더 어렵습니다.

코드 생성에 어떤 문제가 있습니까?

수동 또는 자동으로 코드 생성을 시작하는 것이 더 나은 방법에 대한 까다로운 질문 외에도 코드 생성이 전혀 필요하지 않다고 믿는 사람들이 있음을 언급해야 합니다. 내가 가장 자주 접하는 이 관점에 대한 정당성은 빌드 파이프라인을 설정하는 것이 어렵다는 것입니다. 네, 정말 어렵습니다. 추가 인프라 비용이 있습니다. 특정 제품(jOOQ, JAXB 또는 Hibernate 등)을 이제 막 시작하는 경우 API 자체를 학습하여 가치를 얻을 워크벤치를 설정하는 데 시간이 걸립니다. .

생성기 장치를 이해하는 데 드는 비용이 너무 높으면 실제로 API가 코드 생성기의 유용성에 대해 제대로 작동하지 않은 것입니다(향후에는 사용자 지정도 어렵다는 것이 밝혀졌습니다). 사용성은 그러한 API에 대해 가장 높은 우선순위를 가져야 합니다. 그러나 이것은 코드 생성에 대한 하나의 주장일 뿐입니다. 그렇지 않으면 내부 또는 외부 진리의 로컬 표현을 손으로 완전히 작성하십시오.

많은 사람들이 이 모든 것을 할 시간이 없다고 말할 것입니다. 슈퍼 제품의 마감일이 다가왔습니다. 언젠가는 조립 컨베이어를 빗질하고 시간이 있습니다. 나는 그들에게 대답할 것이다:

독창적 인, Alan O'Rourke, 청중 스택

그러나 Hibernate/JPA에서는 "Java로" 코드를 작성하는 것이 매우 쉽습니다.

정말. Hibernate와 그 사용자들에게 이것은 혜택이자 저주입니다. Hibernate에서는 다음과 같이 몇 가지 엔티티를 간단하게 작성할 수 있습니다.

	@Entity
class Book {
  @Id
  int id;
  String title;
}

그리고 거의 모든 것이 준비되었습니다. 이제 Hibernate의 많은 부분은 이 엔터티가 SQL "dialect"의 DDL에서 정확히 어떻게 정의되는지에 대한 복잡한 "세부 사항"을 생성하는 것입니다.

	CREATE TABLE book (
  id INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
  title VARCHAR(50),
 
  CONSTRAINT pk_book PRIMARY KEY (id)
);
 
CREATE INDEX i_book_title ON book (title);

... 애플리케이션 실행을 시작합니다. 빠르게 시작하고 실행하고 다양한 것을 시도할 수 있는 정말 멋진 기능입니다.

그러나, 내가 보자. 나는 거짓말을 하고 있었다.

• Hibernate는 이 명명된 기본 키의 정의를 실제로 시행합니까?
• Hibernate는 TITLE에 인덱스를 생성합니까? 나는 그것이 우리에게 필요하다는 것을 확실히 압니다.
• Hibernate는 이 키를 ID 사양의 ID 키로 만들까요?

아마 아닐 겁니다. 프로젝트를 처음부터 개발하는 경우 필요한 주석을 추가하는 즉시 이전 데이터베이스를 버리고 새 데이터베이스를 생성하는 것이 항상 편리합니다. 따라서 Book 엔터티는 결국 다음과 같은 형식을 취합니다.

	@Entity
@Table(name = "book", indexes = {
  @Index(name = "i_book_title", columnList = "title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;
  String title;
}

시원한. 재생하다. 다시 말하지만, 이 경우 처음에는 매우 쉬울 것입니다.

하지만 나중에 비용을 지불해야 합니다.

조만간 생산에 들어가야 할 것입니다. 그러면 모델이 작동을 멈춥니다. 왜냐하면:

프로덕션 환경에서는 필요한 경우 이전 데이터베이스를 폐기하고 처음부터 모든 것을 시작할 수 없습니다. 데이터베이스는 레거시 데이터베이스로 전환됩니다.

지금부터 영원히 당신은 써야 할 것입니다 DDL 마이그레이션 스크립트(예: Flyway 사용). 이 경우 엔터티는 어떻게 됩니까? 당신은 그것들을 수동으로 조정하거나(그리고 당신의 워크로드를 두 배로) Hibernate가 당신을 위해 그것들을 재생성하도록 할 수 있다(당신의 기대를 충족시키기 위해 이런 방식으로 생성된 것이 얼마나 가능성이 있는가?) 당신은 어느 쪽이든 잃습니다.

따라서 프로덕션으로 이동하는 즉시 핫 패치가 필요합니다. 그리고 그들은 매우 빨리 생산에 투입되어야 합니다. 프로덕션을 위한 마이그레이션의 원활한 파이프라인을 준비하고 구성하지 않았기 때문에 무리하게 패치를 적용하고 있습니다. 그러면 모든 일을 제대로 할 시간이 없습니다. 그리고 당신은 항상 누군가의 잘못이기 때문에 Hibernate를 꾸짖습니다. 하지만 당신은 아닙니다 ...

대신 처음부터 모든 것이 완전히 다르게 수행될 수 있었습니다. 예를 들어, 자전거에 둥근 바퀴를 달자.

데이터베이스 우선

데이터베이스 스키마의 진정한 "진실"과 이에 대한 "주권"은 데이터베이스 내에 있습니다. 스키마는 데이터베이스 자체에서만 정의되고 다른 곳에서는 정의되지 않으며 각 클라이언트는 이 스키마의 복사본을 가지고 있으므로 스키마와 그 무결성을 준수하고 데이터베이스에서 올바르게 수행하는 것이 합리적입니다. 정보가 저장됩니다.
이것은 진부하기까지 한 오래된 지혜입니다. 기본 및 고유 키가 좋습니다. 외래 키는 괜찮습니다. 제약 조건 확인이 좋습니다. 주장 - 괜찮은.

그리고, 그게 전부가 아닙니다. 예를 들어 Oracle을 사용하는 경우 다음을 지정할 수 있습니다.

• 테이블이 있는 테이블스페이스
• 그녀의 PCTFREE 가치는 무엇입니까
• 시퀀스의 캐시 크기는 얼마입니까(id 뒤)

소규모 시스템에서는 이 모든 것이 중요하지 않을 수 있지만 "빅 데이터" 영역으로 전환될 때까지 기다릴 필요는 없습니다. 위에서 언급한 것과 같은 벤더 제공 스토리지 최적화의 이점을 훨씬 일찍 시작할 수 있습니다. 내가 본 어떤 ORM(jOOQ 포함)도 데이터베이스에서 사용할 수 있는 전체 DDL 옵션 세트에 대한 액세스를 제공하지 않습니다. ORM은 DDL 작성에 도움이 되는 몇 가지 도구를 제공합니다.

그러나 결국 잘 설계된 스키마는 DDL로 손으로 작성됩니다. 생성된 모든 DDL은 근사치일 뿐입니다.

클라이언트 모델은 어떻습니까?

위에서 언급했듯이 클라이언트에는 데이터베이스 스키마의 복사본인 클라이언트 보기가 필요합니다. 말할 필요도 없이 이 클라이언트 보기는 실제 모델과 동기화되어야 합니다. 이것을 달성하는 가장 좋은 방법은 무엇입니까? 코드 생성기로.

모든 데이터베이스는 SQL을 통해 메타 정보를 제공합니다. 데이터베이스에서 서로 다른 SQL 언어로 된 모든 테이블을 가져오는 방법은 다음과 같습니다.

	-- H2, HSQLDB, MySQL, PostgreSQL, SQL Server
SELECT table_schema, table_name
FROM information_schema.tables
 
-- DB2
SELECT tabschema, tabname
FROM syscat.tables
 
-- Oracle
SELECT owner, table_name
FROM all_tables
 
-- SQLite
SELECT name
FROM sqlite_master
 
-- Teradata
SELECT databasename, tablename
FROM dbc.tables

이러한 쿼리(또는 뷰, 구체화된 뷰, 테이블 반환 함수도 고려해야 하는지 여부에 따라 유사한 쿼리)는 다음을 호출하여 실행됩니다. DatabaseMetaData.getTables() JDBC에서 또는 jOOQ 메타 모듈을 사용합니다.

이러한 쿼리의 결과에서 클라이언트에서 사용하는 기술에 관계없이 데이터베이스 모델의 클라이언트 측 표현을 생성하는 것이 상대적으로 쉽습니다.

• JDBC 또는 Spring을 사용하는 경우 일련의 문자열 상수를 생성할 수 있습니다.
• JPA를 사용하는 경우 엔터티 자체를 생성할 수 있습니다.
• jOOQ를 사용하는 경우 jOOQ 메타 모델을 생성할 수 있습니다.

클라이언트 API(예: jOOQ 또는 JPA)가 제공하는 기능의 양에 따라 생성된 메타 모델이 정말 풍부하고 완전할 수 있습니다. 예를 들어 암시적 조인의 가능성을 생각해 보십시오. jOOQ 3.11에 도입됨, 테이블 간의 외래 키 관계에 대해 생성된 메타 정보에 의존합니다.

이제 모든 데이터베이스 증분이 자동으로 클라이언트 코드를 업데이트합니다. 예를 들어 상상해보십시오.

ALTER TABLE book RENAME COLUMN title TO book_title;

정말 이 일을 두 번 하시겠습니까? 어떠한 경우에도. DDL을 커밋하고 빌드 파이프라인을 통해 실행하고 업데이트된 엔터티를 가져옵니다.

@Entity
@Table(name = "book", indexes = {
 
  // Вы об этом задумывались?
  @Index(name = "i_book_title", columnList = "book_title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;
 
  @Column("book_title")
  String bookTitle;
}

또는 업데이트된 jOOQ 클래스. 대부분의 DDL 변경 사항은 구문뿐만 아니라 의미 체계에도 영향을 미칩니다. 따라서 컴파일된 코드에서 데이터베이스 증가로 인해 영향을 받는(또는 받을 수 있는) 코드를 확인하는 것이 편리할 수 있습니다.

유일한 진실

어떤 기술을 사용하든지 항상 일부 하위 시스템에 대한 유일한 진실 소스인 하나의 모델이 있습니다. 또는 적어도 우리는 이를 위해 노력하고 "진실"이 어디에나 있고 동시에 어디에도 없는 기업 혼란을 피해야 합니다. 모든 것이 훨씬 쉬울 수 있습니다. XML 파일을 다른 시스템과 교환하는 경우에는 XSD를 사용하십시오. XML 형식의 jOOQ의 INFORMATION_SCHEMA 메타 모델을 살펴보십시오.
https://www.jooq.org/xsd/jooq-meta-3.10.0.xsd

• XSD는 잘 이해됨
• XSD는 XML 콘텐츠를 매우 잘 표시하고 모든 클라이언트 언어에서 유효성 검사를 허용합니다.
• XSD는 버전 관리가 잘 되어 있으며 이전 버전과의 호환성이 높습니다.
• XJC를 사용하여 XSD를 Java 코드로 변환할 수 있습니다.

마지막 포인트가 중요합니다. XML 메시지를 사용하여 외부 시스템과 통신할 때 우리는 메시지가 유효한지 확인하려고 합니다. 이는 JAXB, XJC 및 XSD를 사용하여 달성하기 매우 쉽습니다. 메시지를 Java 개체로 만드는 Java 우선 설계 접근 방식에서 메시지를 이해하기 쉽게 XML로 렌더링하고 다른 시스템에서 사용할 수 있도록 보낼 수 있다고 생각하는 것은 정말 미친 짓입니다. 이러한 방식으로 생성된 XML은 품질이 매우 낮고 문서화되지 않았으며 개발하기 어렵습니다. 그러한 인터페이스에 대한 서비스 품질(SLA) 수준에 대한 합의가 있었다면 우리는 즉시 그것을 망쳤을 것입니다.

솔직히 말해서 이것은 JSON API에서 항상 일어나는 일이지만 그것은 또 다른 이야기입니다. 다음에 논쟁하겠습니다 ...

데이터베이스: 그들은 동일합니다

데이터베이스로 작업하면 기본적으로 모두 동일하다는 것을 이해합니다. 데이터베이스는 데이터를 소유하고 스키마를 관리해야 합니다. 스키마에 대한 모든 수정 사항은 DDL에서 직접 구현해야 단일 정보 소스가 업데이트됩니다.

소스 업데이트가 발생하면 모든 클라이언트는 모델 사본도 업데이트해야 합니다. 일부 클라이언트는 jOOQ 및 Hibernate 또는 JDBC(또는 둘 다)를 사용하여 Java로 작성될 수 있습니다. 다른 클라이언트는 Perl로 작성될 수 있고(행운을 빌자), 다른 클라이언트는 C#으로 작성될 수 있습니다. 그것은 중요하지 않습니다. 기본 모델은 데이터베이스에 있습니다. ORM으로 생성된 모델은 일반적으로 품질이 낮고 문서화도 잘 되어 있지 않으며 개발하기 어렵습니다.

그러니 실수하지 마세요. 처음부터 실수하지 마세요. 데이터베이스에서 작업합니다. 자동화할 수 있는 배포 파이프라인을 구축합니다. 코드 생성기가 데이터베이스 모델을 편리하게 복사하고 클라이언트에 덤프할 수 있도록 합니다. 그리고 코드 생성기에 대해 걱정하지 마십시오. 그들은 좋다. 그들과 함께하면 생산성이 높아질 것입니다. 처음부터 설정하는 데 약간의 시간을 할애하기만 하면 몇 년 동안 프로젝트의 스토리를 구축할 수 있는 성능이 향상될 것입니다.

나중에 나에게 감사하지 마십시오.

설명

명확하게 하기: 이 기사는 전체 시스템(즉, 도메인, 비즈니스 논리 등)이 데이터베이스 모델에 맞게 조정되어야 한다고 주장하지 않습니다. 이 기사에서 내가 말하는 것은 데이터베이스와 상호 작용하는 클라이언트 코드가 데이터베이스 모델을 기반으로 작동하여 "일류" 상태의 데이터베이스 모델을 재생산하지 않도록 해야 한다는 것입니다. 이러한 논리는 일반적으로 클라이언트의 데이터 액세스 계층에 있습니다.

일부 장소에서 여전히 보존되는 XNUMX단계 아키텍처에서는 이러한 시스템 모델이 가능한 유일한 모델일 수 있습니다. 그러나 대부분의 시스템에서 데이터 액세스 계층은 데이터베이스 모델을 캡슐화하는 "하위 시스템"으로 보입니다.

예외

모든 규칙에는 예외가 있으며 데이터베이스 우선 및 소스 코드 생성 접근 방식이 때때로 부적절할 수 있다고 이전에 말씀드린 바 있습니다. 여기에 그러한 예외가 몇 가지 있습니다(아마도 다른 예외도 있을 것입니다).

• 스키마를 알 수 없고 열어야 하는 경우. 예를 들어 사용자가 다이어그램을 탐색하는 데 도움이 되는 도구를 제공합니다. 휴. 여기에는 코드 생성이 없습니다. 그러나 여전히-우선 데이터베이스입니다.
• 어떤 문제를 해결하기 위해 즉석에서 회로를 생성해야 하는 경우. 이 예는 패턴의 약간 프릴 버전인 것 같습니다. 엔티티 속성 값즉, 잘 정의된 스키마가 없습니다. 이 경우 RDBMS가 적합할지 전혀 확신할 수 없는 경우가 많습니다.

예외는 본질적으로 예외적입니다. RDBMS 사용과 관련된 대부분의 경우 스키마는 미리 알려져 있고 RDBMS 내부에 있으며 "진실"의 유일한 소스이며 모든 클라이언트는 여기에서 파생된 복사본을 획득해야 합니다. 이상적으로는 코드 생성기가 포함되어야 합니다.

출처 : habr.com