真実が先、つまりなぜデータベース構造に基づいてシステムを設計する必要があるのか

おい、ハブル！

私たちはこのテーマについて引き続き調査を続けます。 Java и 春データベース レベルも含みます。本日は、大規模なアプリケーションを設計する際に、Java コードではなくデータベース構造が決定的に重要である理由、その方法、このルールにはどのような例外があるのか​​について説明することをお勧めします。

このかなり遅れた記事では、ほとんどの場合、アプリケーションのデータ モデルは「Java ファースト」(または使用しているクライアント言語) ではなく「データベース ファースト」で設計する必要があると考える理由を説明します。 2 番目のアプローチを選択すると、プロジェクトが成長し始めたときに、長い苦痛と苦悩の道を歩むことになります。

この記事は 一つの質問、Stack Overflow で質問されました。

Redditでの興味深い議論 java の最新バージョンをダウンロード. и / r / programming.

コード生成

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)) {
    // ...
}

コードはビルド外で手動で生成されるか、ビルドごとに手動で生成されます。例えば、このような再生は、 Flywayデータベース移行は手動または自動で実行できます.

ソースコードの生成

コード生成に対するこれらのアプローチ（手動と自動）には、さまざまな哲学、利点、および欠点がありますが、この記事では詳細には説明しません。しかし、一般的に、生成されたコードの重要な点は、システム内外で当然のことと思っている「真実」を Java で再現できることです。ある意味、これはコンパイラがソース コードからバイトコード、マシン コード、またはその他の種類のコードを生成するときに行うことです。つまり、何らかの理由で、別の言語で「真実」の表現が得られるのです。

このようなコードジェネレーターは数多くあります。例えば、 XJC は、XSD または WSDL ファイルから Java コードを生成できます。。原則は常に同じです。

• 何らかの真実（内部または外部）が存在します。たとえば、仕様、データ モデルなどです。
• 私たちのプログラミング言語では、この真実をローカルに表現する必要があります。

さらに、冗長性を避けるために、このような表現を生成することがほとんどの場合に推奨されます。

型プロバイダーと注釈処理

注: jOOQのコード生成に対するもう1つのより現代的で具体的なアプローチは、型プロバイダを使用することです。 F#で実装されているので。この場合、コードは実際にはコンパイル段階でコンパイラによって生成されます。ソース形式では、原則としてそのようなコードは存在しません。 Javaには、アノテーションプロセッサと呼ばれる、あまりエレガントではないが類似のツールがある。 チリ.

ある意味、最初のケースと同じことがここでも起こっていますが、次の点が異なります。

• 生成されたコードは表示されません (この状況は、誰かにとってそれほど不快ではないと思われるかもしれません)
• 型が提供可能であること、つまり「真実」が常に利用可能であることを確認する必要があります。 「真実」を注釈するロンボクの場合、これは簡単です。操作が常に利用可能なライブ接続に依存するデータベース モデルの場合、状況は少し複雑になります。

コード生成の問題は何ですか?

コード生成を手動で実行するか、自動で実行するかという難しい問題に加えて、コード生成はまったく必要ないと考える人がいることも言及する価値があります。私が最も頻繁に遭遇したこの観点の正当性は、ビルド パイプラインを設定するのが難しいということです。はい、本当に難しいです。追加のインフラストラクチャコストが発生します。特定の製品 (jOOQ、JAXB、Hibernate など) を使い始めたばかりの場合は、作業環境の設定に時間がかかるため、その時間を API 自体の学習に費やして価値を引き出す方がよいでしょう。

ジェネレーターの構造を理解するためのコストが高すぎる場合、API はコード ジェネレーターを使いやすくする上で実際には不十分な役割を果たしていることになります (後でカスタマイズも難しいことが判明します)。このような API では、使いやすさが最優先事項になるはずです。しかし、これはコード生成に対する反論の 1 つにすぎません。それ以外の場合、内部または外部の真実のローカル表現を記述するのは完全に手作業になります。

これらすべてを行う時間がないと言う人も多いでしょう。彼らのスーパー製品の締め切りは迫っています。後で組立ラインを徹底的に調べるつもりです。時間はありますから。私は彼らに答えます：

オリジナル, アラン・オルーク、オーディエンス・スタック

しかし、Hibernate/JPA では「Java」コードを書くのは非常に簡単です。

本当に。 Hibernate とそのユーザーにとって、これは祝福であると同時に呪いでもあります。 Hibernate では、次のようにいくつかのエンティティを簡単に記述できます。

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

そしてほぼすべての準備が整いました。ここで、このエンティティが SQL 「方言」の DDL でどのように定義されるかという複雑な「詳細」を生成するのは、Hibernate の役割です。

	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 は、Identity 仕様でこのキーを確実に識別するのでしょうか?

おそらくそうではないでしょう。プロジェクトを最初から開発している場合は、必要な注釈を追加したら、古いデータベースを破棄して新しいデータベースを生成すると便利です。したがって、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などを使用）。その場合、あなたのエンティティはどうなるのでしょうか?手動で適応させるか（作業が 2 倍になります）、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;

本当にこの仕事を2回やりたいですか?いかなる場合でも。 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 の変更は、構文だけでなくセマンティクスにも影響します。したがって、コンパイルされたコードを調べて、データベースの増大によってどのコードが影響を受けるか (または影響を受ける可能性があるか) を確認すると役立ちます。

唯一の真実

どのようなテクノロジーを使用していても、何らかのサブシステムの唯一の真実のソースとなるモデルが常に 1 つ存在します。少なくとも、私たちはそれを目指して、「真実」がどこにでもあると同時にどこにも存在しないような企業の混乱を避ける必要があります。すべてがもっとシンプルになるはずです。他のシステムと XML ファイルを交換するだけの場合は、XSD を使用します。 jOOQ の INFORMATION_SCHEMA メタモデルを XML 形式で見てみましょう。
https://www.jooq.org/xsd/jooq-meta-3.10.0.xsd

• XSDはよく理解されている
• XSD は XML コンテンツを非常に適切にマークアップし、すべてのクライアント言語での検証を可能にします。
• XSD は適切にバージョン管理されており、高度な下位互換性を備えています。
• XSDはXJCを使用してJavaコードに変換できます。

最後の点は重要です。 XML メッセージを使用して外部システムと通信する場合、メッセージが有効であることを確認する必要があります。これは、JAXB、XJC、XSD を使用すると非常に簡単に実現できます。メッセージを Java オブジェクトとして作成する「Java ファースト」設計アプローチを採用した場合、メッセージを意味のある方法で XML にマッピングし、別のシステムに送信して使用できると期待するのはまったくの狂気です。この方法で生成された XML は、品質が非常に低く、文書化されておらず、進化が困難になります。このようなインターフェースにサービス レベル契約 (SLA) があった場合、私たちはすぐにそれを台無しにしていたでしょう。

正直に言うと、これはまさに JSON API で常に起こっていることですが、それはまた別の話で、次回戦います...

データベース：同じもの

データベースを操作すると、それらはすべて基本的に似ていることに気づきます。データベースはデータを所有し、スキーマを管理する必要があります。スキーマに加えられた変更は、唯一の真実のソースが更新されるように、DDL に直接実装する必要があります。

ソースの更新が発生すると、すべてのクライアントもモデルのコピーを更新する必要があります。一部のクライアントは、jOOQ と Hibernate または JDBC (またはそれらすべて) を使用して Java で記述される場合があります。他のクライアントは Perl で書かれているかもしれません (幸運を祈ります)、また他のクライアントは C# で書かれているかもしれません。それは問題ではありません。メインモデルはデータベース内にあります。 ORM によって生成されるモデルは通常、品質が低く、ドキュメント化が不十分で、進化が困難です。

だから間違いをしないでください。最初から間違いをしないでください。データベースから作業します。自動化できるデプロイメント パイプラインを構築します。コード ジェネレーターを有効にすると、データベース モデルを簡単にコピーしてクライアントにダンプできるようになります。コードジェネレーターについて心配する必要はもうありません。それらは良いです。それらを使用すると、生産性が向上します。最初から少し時間をかけて設定するだけで、プロジェクトのストーリーを形作る生産性の向上を何年にもわたって享受できます。

まだ感謝しないでください。後で感謝してください。

明確化

明確に述べますと、この記事は、データベース モデルに合わせてシステム全体 (つまり、サブジェクト領域、ビジネス ロジックなど) を変更する必要があると主張するものではありません。この記事では、データベースと対話するクライアント コードは、それ自体がファーストクラスの状態でデータベース モデルを再現しないように、データベース モデルと一貫性のある方法で動作する必要があることを主張します。このロジックは通常、クライアントのデータ アクセス層に配置されます。

一部の場所では依然として 2 層アーキテクチャが残っていますが、そのようなシステム モデルが唯一可能なモデルである可能性があります。しかし、ほとんどのシステムでは、データ アクセス層はデータベース モデルをカプセル化する「サブシステム」であるように思われます。

例外

すべてのルールには例外があり、データベースファースト、ソースコード生成のアプローチが不適切になる場合があることはすでに述べました。以下に、そのような例外をいくつか示します (おそらく他にも例外はあります)。

• 回路が不明で発見する必要がある場合。たとえば、ユーザーが任意の図をナビゲートするのに役立つツールを提供しているとします。ふう。ここではコード生成は行われません。しかし、やはりデータベースが最優先です。
• 何らかの問題を解決するために回路を即座に生成する必要がある場合。この例は、パターンの少し派手なバージョンのように思えます。 エンティティ属性値つまり、明確に定義されたスキームが実際には存在しないということです。この場合、RDBMS が適切であるかどうかを確認することは不可能であることがよくあります。

例外は本質的に例外的なものである。 RDBMS が関係するほとんどの場合、スキーマは事前にわかっており、RDBMS 内に存在し、唯一の「真実」のソースであり、すべてのクライアントはそこから派生したコピーを取得する必要があります。理想的には、これにはコード ジェネレーターを使用する必要があります。

出所： habr.com