このページは、以下の英語ページの抄訳です。
https://blogs.sap.com/2014/01/14/orms-and-key-generation/
この記事のオリジナルは、Glenn Paulley が sybase.com に 2009 年 2 月に掲載したものです。その中で、Glenn は SQL Anywhere の hibernate におけるプライマリーキーの生成と使用に関する洞察について述べています。
このブログの掲載以降、SQL Anywhere の hibernate における方言は新バージョン用にアップデートされ、GitHub からダウンロードできます here。この方言の新しい版では、 UDUID や シーケンスベースのキー生成もサポートされています。Hibernate 識別子やキー生成に関しては、 hibernate documentation でも解説されているので参照してください。
オブジェクト関係マッピング (Object-relational mapping、ORM) ツールで一般的な問題は、オブジェクトの識別です。
簡単に言うと、リレーショナルデータベースの中の永続すべき 2 つのオブジェクトがプログラミング言語内で異なるオブジェクトインスタンスであった場合に、これらの識別を保証することが問題になります。
例えば、Minter 氏 と Linwood 氏 [1] は、Hibernate に関するオブジェクト識別について [pp. 213] で以下のように述べています。
First and foremost, Hibernate wants every entity to be identifiable with a primary key. Ideally, it would like this to be a surrogate key (a single column distinct from the fields of the table). Hibernate will access a primary key that is not a surrogate key. For example, the username column might be used to uniquely identify an entry in the user table. Hibernate will also access a composite key as its primary key, so that the username and hostname might be used to form the primary key if the username alone did not serve to identify the row.
（抄訳）まず、 Hibernate はプライマリーキーで全てのエンティティを識別することを望みます。理想的には、これがサロゲートキー（テーブルのフィールドから明確である単一のカラム）であることを望みます。Hibernate は、サロゲートキーでないプライマリーキーにアクセスします。例えば、ユーザー名カラムは、ユーザーテーブルのエントリーをユニークに識別するために使用される可能性があります。Hibernate は、ユーザー名だけではローを識別できない場合に、プライマリーキーを形成するためにユーザー名とホスト名を使用できるよう、複合キーにもプライマリーキーとしてアクセスします。
現実はこうは機能しません。一般的なデータベースであればプライマリーキーがオミットされたテーブルが少なくとも１つあります。
例えばテーブルのコンテンツは、他のテーブルとの関係に絡む必要はありません。データベース設計として優れたものでなくても、 Hibernate がデータにオブジェクトをマップしようとした時に初めてエラーが露見します。
適切なサロゲートキーの追加はオプションかもしれません --- そうであれば、我々はそうするよう薦めます。
実際には基礎となるスキーマは開発者がコントロールできるものではないかもしれません。あるいは、スキーマが根本的に変更されると他のアプリケーションが壊れてしまうかもしれません。
ActiveRecord.js のような ORM 実装によっては、データベースをサポートする identity カラムがプライマリーキーとして機能する必要があります。ユーザー定義の PK 実装と以下を含む Hibernate をサポートするサロゲートキージェネレーターのどちらのサポートも提供しており、Hibernate はより堅牢です。
- increment (複数のコンカレントクライアントには不適切)
- GUID
- hilo (SQL Anywhere の
GLOBAL AUTOINCREMENTに似たもの)
- identity (SQL Anywhere の
AUTOINCREMENTに似たもの)
- seqhilo
- sequence (ANSI シーケンスの Oracle の実装。
AUTOINCREMENTに似たもの)
- UUID (GUID に似たもの)
Hibernate 3.2.3 以降では、さらに２つのジェネレーターをサポートしています:
- org.hibernate.id.enhanced.SequenceStyleGenerator - ANSI シーケンスをミミックするために設計された数値ジェネレーターを実装
- org.hibernate.id.enhanced.TableGenerator - 複数の明確にキー化されたローを使用することで同時に異なるインクリメント値を複数保持できる複数のテーブルを定義
どちらを選択すべきでしょうか ? SQL Anywhere では、SQL Anywhere サーバーにビルトインされたそれぞれを利用することで SQLAnywhere10Dialect は GUID も
IDENTITY (
AUTOINCREMENT または
GLOBAL AUTOINCREMENT) もサポートしています。
開発者によっては、これらは「自然な」フィットであると感じるかもしれません。なぜならば、これらはビルトインのプリミティブで、スケーラブルであり、レプリケーションが絡む分散データベース設計の場合の多くの問題のいくつかを軽減するからです。これらの欠点は、
以前書いたように この種の識別子では特にそれらが特定のエンティティに対して
唯一のプライマリーキーとして機能する場合に、ユーザーにとって大きな負担になる可能性があります。
例えば、プライマリーキーとして GUID を使用することを検討するでしょうか ? GUID は間違いなく型に当てはめるのが難しいものです。長さも長く、アプリケーション開発者にとって便利なセルフチェッキングスルー的なものではありません。
GUID よりも適切な「お客様識別子」の構築の方に努力を費やすつもりであれば、キー生成アルゴリズムが確実にスケールするようにする必要があります。
Hibernate 3.2.3 に導入された TableGenerator テクニックには、新たに挿入されたオブジェクトそれぞれのためのキーテーブル更新に関わるコンテンションが原因で、非常に大規模なワークロードに対して不十分なスケーラビリティー（コンボイまたはデッドロック）が潜在すると思っています。
私はこのタイプの問題に関する現実の例について、
SQL Anywhere のキャパシティ計画のホワイトペーパーで Ivan Bowman とともに解説しています。
必然的に、サロゲートキーの選択技術は、トレードオフになります。
データベースシステムが様々なキージェネレーターとカスタマイズ（フォーマット、セルフチェック機能、長さ、など）をサポートすれば便利なものになるでしょう。
それまでは、これらはアプリケーション内で開発することになります。Hibernate のような ORM ツールキットでは、カスタマイズされたキージェネレーターを直接的にツールのインフラに埋め込んで全てのアプリケーションで利用可能にすることは不可能です。
[1] Dave Minter and Jeff Linwood (2005).
Pro Hibernate 3. Apress Press, Berkeley, California. ISBN 1-59059-511-4.
===
SQL Anywhere に関してはまずは
こちらをご参照ください。無期限でご利用いただける無償の Developers Edition もこちらからダウンロードが可能です。
その他 や、
SAP SCN Wiki などもご参照ください。
SQL Anywhere に関して技術的な質問のある方は
コミュニティに登録し、
「Ask a Question」機能をご利用ください。
Language には「Japanese」、
Primary Tag には「SAP SQL Anywhere」を選択
User Tagに「sql anywhere」「sql anywhere Japanese question」
を入力してください。
不具合につきましては、サポート契約者様専用の問い合わせ方法にてお問い合わせください。
======================
ご購入に関するお問い合わせ
こちらよりお問い合わせください。
