DBFluteのサポート情報
対応プログラミング言語
- Java5 @until 0.9.9.5B
- Java6 @until 1.0.x
- Java7 @until 1.0.x
- Java8 以降 @since 1.1.0
- C#-3.0 *DBFlute.NETにてサポート
対応データベース
正式サポート
ほとんどの機能が利用可能で、テスト環境も用意され、積極的にサポートされているデータベースです。
- MySQL
- PostgreSQL
- Oracle
- DB2
- SQLServer
- H2 Database
- Apache Derby
準サポート
機能制限が多く積極的なサポートはありませんが、テスト環境も用意されているデータベースです。
- SQLite @since 0.9.7.0
若干サポート
DBMS の違いを吸収するクラスは用意されていますが、テスト環境はなく、ユーザからのフィードバックのみで動作が確認されているデータベースです。
- Firebird @since 0.9.7.5
- Sybase @since 0.9.7.6
- MS Access @since 0.9.7.0
Aurora や Percona は？
MySQLのフォークである Amazon Aurora や Percona は、正式サポートの中に明記されていませんが、それらDBMSがMySQLとの互換性を保っている限り動作するでしょう。 (MySQLのJDBCドライバーで、MySQLと変わらずアクセスできる限り。PostgreSQL互換の Amazon Aurora も同様に)
もし将来、それらDBMSでMySQLと違う挙動が発生して困ることがあれば、フィードバックを頂ければ可能な範囲でDBFlute側で対応したいとは思います。 個人的に見聞きする範囲で、実際に Amazon Aurora や Percona を DBFlute で使っている現場もありますので。
他でも、互換性を保っているフォークDBに関しては、このようなスタンスです。フォーク元のDBMSがDBFluteのサポート対象であれば、DBFluteでも利用できるでしょうと考えます。
対応DIコンテナ
- Lasta Di
- Spring Framework
- Google Guice
- Seasar
- CDI (JSR-299)
対応OS
DBFluteの自動生成処理の実行環境として、以下の環境をサポートしています。
- Mac OS X
- Linux (Ubuntsuも含む)
- Windows
Mac OS X、および、Linux では、DBFluteタスクは bash で動作します。
サポートされない名前
SQL上でクォートの必要な名前
SQL上でもクォートしないと利用できないテーブル名やカラム名は正式にはサポートされません。 例えば、SQL上の予約語や日本語テーブル(和名テーブル)、日本語カラム(和名カラム)などが該当します。
ニュアンスとしては、"クォートするオプションはあるが積極的なサポートはしていない" (例えば、詳細なテストはしていない)というところです。 また、これら機能は TwoEdgedSword 認定されています。dbflute-mysql-example にて Example があります。
外だしSQLや別のツールでのSQLで不利益であることに変わりはないため、基本的にはDB上の名前を変更するか、ビューやシノニムを作ることが推奨されます。
プログラム上の予約語になる名前
プログラム上の予約語になるテーブル名やカラム名は正式にはサポートされません。 (例えば、"class" や "public" など)
ニュアンスとしては、"自動解決する機能はあるが積極的なサポートはしていない" (例えば、詳細なテストはしていない)というところです。全ての予約語には対応しておらず、代表的な "class" や "public" など一部の予約語のみ対象となっており、かつ、カラム名に限定されています(テーブル名は、ProjectPrefix で回避できるかもしれませんが確認されていません)。また、この自動解決する機能自体が TwoEdgedSword 認定されています。dbflute-mysql-example にて Example があります。
外だしSQLや別のツールでのSQLで不利益であることに変わりはないため、基本的にはDB上の名前を変更するか、ビューやシノニムを作ることが推奨されます。
プログラム上でコンパイルエラーになる名前
"-" (ハイフン)や空白(半角スペース)などのプログラム上のクラス名などでコンパイルエラーとなるような名前、および、"$" が入ったテーブル名やカラム名はサポートされません。
ニュアンスとしては、"解決するオプション、特殊な利用方法はあるが積極的なサポートはしていない" (例えば、詳細なテストはしていない)というところです(@since 0.9.7.2)。 また、この機能は TwoEdgedSword 認定されています。dbflute-postgresql-example にて Example があります。
外だしSQLや別のツールでのSQLで不利益であることに変わりはないため、基本的にはDB上の名前を変更するか、ビューやシノニムを作ることが推奨されます。
大文字小文字やアンダースコア区別なしで同名
例えば、"foo_date", "foo_DATE", "fooDate" といった、大文字小文字やアンダースコア区別なしで同名となるテーブル名や、カラム名が同時に存在するのはサポートされません。 DBFluteは基本的に、テーブル名やカラム名を大文字小文字やアンダースコア区別なしで同じ場合は同じものと判断します。
仕様という面を置いておいても、業務的にもそういった紛らわしい名前は非推奨です。しっかりと違いのわかる意味のある名前を付けることをお奨めします。 どうしても変更できない場合は、該当テーブルは自動生成対象外にして、ビュー経由で自動生成することをお奨めします。
名称変更、もしくは、ビュー・シノニム回避
DBFluteの Behavior や ConditionBean などの機能で、サポートされない名前のテーブルを扱えるようにしても、 結局は、外だしSQLや別のツールでのSQLで不利益なことは変わりません。
なので、できることなら特殊な記号を使ったりしないような名前に変更することをお奨めします。 どうしても変更できない場合は、該当テーブルは自動生成対象外にして、ビューやシノニム経由で自動生成することをお奨めします。
非推奨データ構造
完全なサポート外にはなりませんが、一部機能で制限が出てくる可能性のある構造があります。 これら構造は、DBFluteではそもそも推奨されないDB設計となります。
PKのないテーブル
PKのないテーブルでは、Behavior や ConditionBean などの更新系メソッドは利用できません。登録処理(insert)のみオプションで利用できます。
複合主キー
複合主キーでは、そのもの自体が持つSQLへの制限などから、DBFluteでの機能も限られます。 複合主キーのその他デメリットを考えても、DBFluteでは推奨されません。
制約のないPK/FK/UQなど
実際には PK/FK/UQ の役割のカラムがあるのにも関わらず、制約が付いていない場合は、DBFluteプロパティにて手動で定義する必要があります。
桁数の満たないchar型データ
例えば、char(3) と定義されているカラムに、"AB" という二文字のデータを登録するような構造は強く非推奨です。
大文字小文字区別なし等値のPKで別レコード
大文字小文字区別なしで等しくなるPKの値、例えばPK値が "FOO" と "foo" で別レコードの分かれるような構造は強く非推奨です。そのような場合、一部機能においてサポートされません。 LoadReferrer や区分値メソッドでは、PK値(コード値)を大文字小文字を区別せずに処理します。 (ここでいうPKには、FKされるUQも含まれます)
"データの大文字小文字を区別するかどうかのDB上の設定" 自体は、どちらでもサポートされます。 大文字小文字区別なしで等しくなるPKの値さえなければ、大文字小文字を区別する設定でも問題ありません。
統一性のない共通カラム
多くのテーブルで定義される共通カラム、例えば、登録日時、更新ユーザなどのカラムの名前が、テーブルごとにバラバラの場合(update_user だったり、upd_usr だったり)、共通カラムの自動設定の機能が利用できない可能性があります。
その他、RDB 的でない構造
その他、リレーショナルデータベース的でない構造は推奨されません。 例えば、カラムデータの中に複数の値を集約して、何桁数目から何桁が FOO データ、その次の何桁が BAR データというようなコードをロジックとして必要とする構造です。 単なる、人が見やすいコード、というためだけに利用するならよいですが、プログラム上で分解して利用するようなものは強く非推奨です。
