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

おい、ハブル！

私たちはこのテーマについて研究を続けています Java и 春データベースレベルも含めて。 今日は、大規模なアプリケーションを設計するときに、決定的に重要なのは Java コードではなくデータベース構造である理由、これがどのように行われるか、そしてこの規則にはどのような例外があるのか​​について読んでいただくことをお勧めします。

このかなり遅れた記事では、ほとんどすべての場合、アプリケーションのデータ モデルは「Java の機能」(または使用しているクライアント言語) ではなく「データベース」に基づいて設計されるべきであると私が考える理由を説明します。一緒に働く）。 XNUMX 番目のアプローチを取ると、プロジェクトが成長し始めると、痛みと苦しみの長い道を歩むことになります。

この記事は以下をもとに書かれました 一つの質問、スタックオーバーフローで与えられます。

reddit での興味深いディスカッションをセクションごとにまとめたもの /r/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 のコードを生成する別の、より現代的で具体的なアプローチは、タイプ プロバイダーを使用することです。 F# で実装されているため、。 この場合、コードはコンパイラによって、実際にはコンパイル段階で生成されます。 原則として、そのようなコードはソース形式では存在しません。 Java には、それほどエレガントではありませんが、同様のツール (アノテーション プロセッサなど) があります。 チリ.

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

• 生成されたコードは表示されません (おそらく、この状況にあまり不快感を感じない人もいるでしょうか?)
• 型を提供できることを確認する必要があります。つまり、「true」が常に使用可能である必要があります。 「真実」に注釈を付けるロンボク島の場合、これは簡単です。 常に利用可能なライブ接続に依存するデータベース モデルの場合は、少し複雑になります。

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

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

ジェネレーターの構造を理解することに関連するコストが高すぎる場合、確かに、API はコード ジェネレーターの使いやすさに関して不十分な仕事をしていたということになります (そして、その後、コード ジェネレーターでのユーザーのカスタマイズも難しいことが判明しました)。 このような API では、使いやすさが最優先される必要があります。 しかし、これはコード生成に対する反論の XNUMX つにすぎません。 それ以外の場合、内部または外部の真実のローカル表現を記述するのは完全に手動です。

多くの人は、これすべてを行う時間がないと言うでしょう。 彼らはスーパープロダクトの期限を過ぎています。 いつか組み立てコンベアを整理整頓します、時間はあります。 私はそれらに答えます：

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

しかし、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 はこのキーを 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 を使用したものなど)。 この場合、あなたのエンティティはどうなるでしょうか? これらを手動で適応させる (つまり、ワークロードが XNUMX 倍になる) か、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;

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

唯一の真実

どのようなテクノロジを使用するかに関係なく、サブシステムにとって唯一の真実の情報源となるモデルは常に XNUMX つあります。あるいは、少なくともこれを目指して努力し、「真実」がどこにでも存在し、同時にはどこにも存在しないような企業の混乱を避ける必要があります。 。 すべてがもっとシンプルになる可能性があります。 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 を使用して生成されたモデルは通常、品質が低く、文書化が不十分で、開発が困難です。

だから、間違いを犯さないでください。 最初から間違えないようにしましょう。 データベースから作業します。 自動化できるデプロイメント パイプラインを構築します。 コード ジェネレーターを有効にすると、データベース モデルを簡単にコピーしてクライアントにダンプできるようになります。 コードジェネレーターについて心配するのはもうやめましょう。 彼らは良い。 これらを使用すると、生産性がさらに向上します。 最初からそれらをセットアップするのに少し時間を費やすだけで済みます。そうすれば、何年にもわたる生産性の向上が待っており、それがプロジェクトの歴史を作り上げることになります。

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

明確化

明確にしておきます: この記事は、データベース モデルに合わせてシステム全体 (つまり、ドメイン、ビジネス ロジックなど) を変更する必要があると主張するものではありません。 この記事で私が言いたいのは、データベースと対話するクライアント コードは、データベース モデルに基づいて動作する必要があるため、それ自体がデータベース モデルを「ファーストクラス」の状態で再現しないようにする必要があるということです。 このロジックは通常、クライアントのデータ アクセス層にあります。

いくつかの場所でまだ保存されている XNUMX レベルのアーキテクチャでは、そのようなシステム モデルが唯一可能なものである可能性があります。 ただし、ほとんどのシステムでは、データ アクセス層はデータベース モデルをカプセル化する「サブシステム」であるように私には思えます。

例外

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

• スキーマが不明であり、検出する必要がある場合。 たとえば、あなたは、ユーザーが任意の図をナビゲートできるようにするツールのプロバイダーであるとします。 うーん。 ここではコード生成は行われません。 しかし、それでもデータベースが最優先です。
• 問題を解決するために回路をオンザフライで生成する必要がある場合。 この例は、パターンの少し空想的なバージョンのように見えます。 エンティティの属性値つまり、明確に定義されたスキームが実際にはありません。 この場合、RDBMS が自分に適しているかどうかさえ確信が持てないことがよくあります。

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

出所： habr.com